Hey Nic,
Thanks for the feedback!
1. I don't think it'll overly complicate the form tag. Most of the
logic is already present today in the stripes:wizard-fields tag. I'm
not quite sure which way I'm going to move things. I may simply have
the form tag instantiate and use the wizard-fields tag whenever it
encounters a wizard form. Or maybe move the wizardy code into helper
class.
The form tag already shares some of the logic too, for managing the
submission of fields that may not even submit a key if they are empty/
non-selected (radios, checkboxes, multi-selects). Most of the
machinery is there, so I'm not overly worried about this.
2. I did think about this, and I think to do it _right_ involves
either being non-multi-window safe, or runs the risk of having lots
of orphaned data in session. The reason I like the hidden field
approah is that if someone pops open a second window half way through
the flow and takes two different routes, they are independent of each
other (or at least can be). To do that using session you'd have to
generate a new key field every time the user was presented with a
form, and manage the removal and clean up of abandoned sets of wizard
information in session. It's definitely doable, but it seems more
complex to manage....
-t
On Jan 11, 2006, at 10:43 AM, Nic Holbrook wrote:
> Sounds like a good start. You've thought this out
> pretty well. I have a couple of questions I would
> like to present.
>
> 1. Will the wizard tag logic overly complicate the
> main form tag and make it hard to maintain? I really
> like annotations, but just wanted to see how much
> extra logic will be added to the tag. Would it be
> cleaner to have a <stripes:wizardForm> tag?
>
> 2. Hidden fields will work, but I was just curious as
> to why you don't generate an encryped key and store
> the wizard form data in the session until it completes
> at which time it can be discarded?
>
> I like your ideas. I'm just trying to throw out some
> alternates to see if they have been considered.
>
> Thanks
>
> Nic Holbrook
>
>
> --- Tim Fennell <hidden> wrote:
>
>> Hi Everyone,
>>
>> Firstly, welcome to the new, reduced size
>> Stripes-Dev list. It's
>> down to 9 people now, and I think everyone on the
>> list has some
>> interest in the direction Stripes is taking. As a
>> result I hope to
>> use this as a sounding board. I'm hoping that you
>> will take a little
>> time to really think about things that I post here
>> and offer my
>> feedback! Let's see how it works.
>>
>> I've been putting the building blocks in place
>> during the last couple
>> of releases to introduce a good wizard pattern
>> implementation in
>> Stripes. What I mean by wizard is really one
>> logical form/submission
>> that is broken across multiple pages from the user's
>> perspective.
>> Either because there's just too much to display on
>> one page, or
>> because there are decision points and different sets
>> of fields would
>> be displayed to the user based on input. The
>> classical example is
>> the registration flow where you're forced to enter
>> reams of personal
>> information to sign up for a sight ;)
>>
>> The way I've done this before (and intend to do it
>> in Stripes) is
>> through the automatic writing of hidden fields on
>> the JSP to carry
>> input from earlier pages forward (and later pages
>> backward when there
>> is backward navigation too). They key to this
>> approach is being able
>> to correctly apply required field validation for
>> only those fields
>> that show up on the JSP. But also to validate all
>> required fields
>> when the final submission is made.
>>
>> If you've played with the 'wizard-fields' tag,
>> you'll have gotten the
>> basic idea for what I'm planning. In the last
>> version of Stripes I
>> added the mechanism so that the form tag can write
>> out a 'fields
>> present' hidden field that lists out the checkboxes
>> and selects
>> present on the page in order that they can be
>> validated correctly if
>> the user does not enter a value.
>>
>> So, here's what I'm planning. A form will somehow
>> (more in a bit)
>> identify the fact that it is a wizard form. When a
>> wizard form is
>> processed, in the doEndTag of the form the following
>> will be done:
>> - Write out hidden fields for all values in the
>> request for which a
>> form field was not present in the form
>> - of course, excluding things like the parameter
>> that identified
>> the event etc.
>> - Write out the 'fields present' hidden field so
>> the server will
>> know which fields to do req'd field validation on
>>
>> The first decision I need to make is how to identify
>> a form as a
>> wizard. I'm leaning strongly towards another
>> annoation on the
>> ActionBean, @Wizard. It's presence would inform the
>> form tag that
>> the form should be treated as a wizard. The other
>> option I can think
>> of would be to add an attribute to the <form> tag.
>> The upside of the
>> annotation is that it's done once, and it's clear in
>> the Java code
>> that it's a wizard. The downside is that it would
>> make it a little
>> strange (though not impossible) to use the action
>> bean in a non-
>> wizard manner. Thoughts?
>>
>> The second decision is how to ensure that when the
>> final submission
>> occurs that we really validate all the required
>> fields properly. Up
>> until now the 'fields present' has been a hidden
>> field written in
>> plain text. So it'd be a little easy to circumvent
>> required field
>> validation if a user was malicious. The options I
>> can think of are:
>> 1. Mark the 'final' event somehow
>> (@FinalWizardEvent, @Wizard
>> (final="save") etc.)
>> 2. Encrypt the 'fields present' that gets written
>> to the browser
>> 3. Store the 'fields present' on the server and
>> place a unique key
>> in the hidden field
>>
>> For me it's a toss-up between 1 and 2. Marking an
>> event as final
>> would trigger full-scale required field validation
>> (anything marked
>> as required would be validated). This has a
>> downside in that if
>> different paths through the wizard had different
>> required fields then
>> you couldn't use the built in required field
>> validation to validate
>> them.
>>
>> Option 2 would probably involve generating a
>> disposable encryption
>> key the first time any wizard is rendered in a
>> user's session, and
>> storing the key in the session. That could then be
>> used to encrypt
>> the list of fields that have been presented to the
>> user before it is
>> pushed into a hidden field on the page. And so, if
>> a wizard form
>> gets submitted and this value is missing or can't be
>> decrypted then
>> you know someone has monkeyed with it. And because
>> you'd have a
>> bullet-proof (resistant?) list of fields that had
>> been presented to
>> the user, you could validate only those fields -
>> allowing different
>> required field validation for different flows in the
>> wizard.
>>
>> So, to summarize. I think I'm leaning toward an
>> @Wizard annotation
>> to identify wizards, and using an encrypted hidden
>> field to pass the
>> list of fields that the user has been presented
>> with. What do you
>> all think of this solution?
>>
>> -t
>>
>>
>>
> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do
>> you grep through log files
>> for problems? Stop! Download the new AJAX search
>> engine that makes
>> searching your log files as easy as surfing the
>> web. DOWNLOAD SPLUNK!
>>
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> Stripes-development mailing list
>> hidden
>>
>
https://lists.sourceforge.net/lists/listinfo/stripes-development
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
>
http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD
> SPLUNK!
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Stripes-development mailing list
> hidden
>
https://lists.sourceforge.net/lists/listinfo/stripes-development
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Stripes-development mailing list
hidden
https://lists.sourceforge.net/lists/listinfo/stripes-development
Re: [Stripes-dev] Wizard pattern implementation
