re: proposal for validating action to be used with intake

[Guido Sohne <ca...@yahoo.com>]

 James Coltman wrote:

> Guido,
>
> Thanks for the email. I had looked at your code before but I just
> hadn't got round to replying. Apologies. Unfortunately John who was
> the original creator of Intake seems to be a bit AWOL at the moment so
> you may have
> difficulty getting anything out of him.

I'm sorry to hear that. I hope he will be back soon.

> In brief I thought you're proposed action seems to add a lot of value
> and significantly reduces the amount of code required in the business
> specific action implemented by the developer. So a big +1 there.
>
> With regard to the failure and success screens as you probably know
> the current approach is to use the setPage method in the vm to specify
> the failure page, and a nextTemplate hidden field to specify the
> success screen. I quite like this approach as it means both screens
> are completely controlled by the designer rather than the developer. i.e.
>
> <form method="post"
>
action="$link.setPage("employer,application,CompanyDetail.vm").setAction("Ap
ply")"

> >
> <input type="hidden" name="nextTemplate"
> value="employer,application,DirectorDetail1.vm">
>

Sounds good. I have not been using this way of determining which screen
to go to next and like the way it gives control to the designer rather
than the developer. I will change my project's code to reflect this.

With this change, validating actions can be done in an even cleaner way
because the screen to go to after the action is complete will not have
to be specified. One thing I do not like about it though is that it
leads to implicit logic. You no longer explicitly specify the
destination to go to within the code and a new Turbine user who is
reading documentation will have to stumble upon this fact.

Keeping that in mind, it should not be compulsory to use either
approach. The ValidatingAction class should be smart enough to look for
a parameter called nextTemplate and use that to set the success screen.
If this parameter exists in the key/value pairs that
rundata.getParameterParser() returns then the failure page and success
page can be set automagically.

>
> In this scenario the developer will only use the setTemplate in his
> code method when a success occurs otherwise he will do nothing. I
> would be interested to hear you comments about this approach and how
> you could see it
> fitting in with your proposed action.
>

I've done some refactoring, added some more javadoc and implemented
support for the nextTemplate approach. I'll attach the new version of
the code after this message. I hope that there is a better way to
discuss changes like this without having to post the code in question
each time there's a change in response to discussions on the issue.

>
> My other thoughts reflects changes that I feel need to be made to
> Intake itself. Up to now Intake has been primary designed for a one
> form page that maps to a single data object which is normally a peer
> but could be business
> object that reflects the elements in the form.
>
> In my case I am building a multiple page application for a financial
> product. My groups don't always map directly to data objects and I'm
> reluctant to create multiple business objects that merely mirror the
> Group objects. I also have the requirement that users can save half
> completed forms and be able to jump back to earlier pages to make
> updates to the data they entered. To meet these requirement I have
> identified three updates that I need to do to Intake:
>

To my way of thinking, the multiple pages of your application should be
considered as a single group!

Intake could probably do with some inheritance mechanism that allows
aggregation of previously defined groups so that more complex
requirements such as yours could be handled while enabling reuse of
smaller groups defined elsewhere.

>
> 1. Create an XML attribute that specifies that a field shouldn't be
> mapped to a property.

I don't like this much. Mapping fields to properties allows things to be
done in a cleaner and generic way. -1 on this.

>
> 2. Create a mechanism for getting a copy of a group object (currently
> the group object is only returned as a reference) that can be stored
> in the session.
>
> 3. Create a mechanism for putting a group object in a session back
> into Intake.
>

Intake could be extended to mark a particular group as being able to
span requests i.e. session scope for pull side of intake. Since the
Intake service will still be resident in memory, it should be as simple
as creating a session scope intake pull tool or by extending the
existing intake tool to handle both request and session scope.

Adding functions to intake that would mark a particular group as request
scoped or session scoped could result in transferring the group instance
to be available for one scope or the other but not both. Of course, one
would have to change the scope back to request after validation is
complete.

This is perhaps what you mean in 2. and 3.

>
> I have looked at Intake in detail and the second two update will
> probably need some sort of refactoring of the code. Unfortunately I'm
> up to my eye balls with a project at the moment and I don't have a
> great deal of time to make changes.
>

Your itch [:)]

>
> I don't know whether this will affect your action but I thought it was
> worth mentioning.
>
I doubt it will be a problem. I expect that IntakeTool.isAllValid()
would know the difference between session and request scoped groups. The
only place I can see where change might be necessary would be in
executeEvents() - just before the action returns it can check if
finalTemplate (from form input) is true and if true, change the group
scope to request if the group scope is session.

Anyone who knows more about Intake and Pull can correct me if I am
wrong, of course!

>
> In summary I think the action is a good idea. I would like to see it
> support the current way of submitting the success and failure pages
> (maybe it can and I just haven't understood it properly). I would also
> ask you to reflect on whether some of the functionality would be
> better being part of Intake itself such as the retrieve method. In the
> short term you should probably
>

I guess most of the code can end up somewhere inside Intake. That makes
a lot of sense. However, it is nice to just be able to inherit from the
class and get to implementing business logic without worrying about
getting the intake tool from context, keeping track of state etc.

> try and submit what you currently have and then people can build on it
> if they feel it doesn't meet their needs.
>
This is what I have now and I am hoping that the peer review process can
improve upon it, in fact - it already has :)

Feel free to refactor it into Intake if that seems a good idea. If that
is necessary later, I'm sure the action can be changed to be a wrapper
over the functionality that migrates into Intake proper.

The refactored code incorporating your suggestions is attached to this
message. Any ideas on which package this would best fit into ?

>
> Hope this helps,
>
> James
>
> P.S. Feel free to submit this mail to turbine-dev/tubine-user if
> required.
>

Done!! I'm keeping my original message included so others can get a
handle on this discussion.

>
>
> -----Original Message-----
> From: Guido Sohne [ mailto:caught_one@yahoo.com]
> Sent: 13 June 2001 05:48
> To: John McNally; James Coltman
> Subject: validation with intake
>
>
> I sent some ideas to the list but nobody bit.
>
> I follow both turbine-user and turbine-dev and have noticed that it is
> basically only a few people who use Intake right now on the list. Not
> really surprising considering it has only recently been documented and
> it is not in the TDK newapp where people can see how and where it can
> be used.
>
> I'm trying to get validation to be as simple as possible to retrofit
> to existing code while ensuring that the full power of intake can be
> made available to those who need it. With this goal in mind, here's
> what I worked
> out.
>
> Attached is some code from one of my projects that uses validation as
> well as a class that help integrate validation into actions with a
> minimum of coding. I'm eager to hear any comments and whether this is
> in fact a good
> idea / direction.
>