I'm probably missing something obvious here, since nobody else has mentioned it so far, but wouldn't the simplest way of achieving what you want be to *not* use session-scoped form beans?
If each page includes the data for all of the wizard pages, then reset() can safely reset all of the fields in the form bean, in the knowledge that the request will contain the values for all of those fields. Simply use hidden fields for those fields which are not part of the visible page, and those values will be safely round-tripped for you, without having to worry about session data and selective resetting of fields. -- Martin Cooper > -----Original Message----- > From: Brian Topping [mailto:topping@;digidemic.com] > Sent: Sunday, November 10, 2002 11:21 PM > To: [EMAIL PROTECTED] > Subject: Unclear semantics on form use for "wizards" > > > Greetings all, > > I'm trying to get my head out of the sand with regard to use of > DynaActionForms whose contents persist across multiple action > invocations. I > guess this is commonly called the "wizard" case. I'm hoping > you guys can > shed some light on my damage WRT this issue (I'll manage the > other damage > separately ;) My understanding is: > > a) this should be possible and is encouraged > b) that doing so is enabled by setting the scope attribute on > the action item > to 'session' > > If these are true, I believe current source tree to be broken > in this regard, > as I do not see a code path through > RequestProcessor.processPopulate() that > does not call form.reset(), nor a path through > DynaActionForm.reset() that > will leave the current values intact based on the scope of the form. > > Having said that, how is it possible to create a form that > can live across > Action invocations? Implementing a subclass of > DynaActionForm with a custom > reset() would require some kind of external interlock to > ensure that it could > be reset when we really truly did want it to be reset (like > when the form was > created). Alternately to an interlock, the form could be > completely disposed > at the end of a wizard sequence, forcing the framework to > recreate it. In > that case, the constructor for the subclass would have to > call the superclass > reset() in order to read in the initial values from the > <form-property> > elements. This seems counter-intuitive and I'm guessing just > an oversight, > given the power provided by <form-property> elements. > > If in fact my head is threaded correctly and screwed on > tight, it would seem > that the fix would be to move the call to processPopulate() at > RequestProcessor.java:251 to a new line after line 369, > thereby only calling > reset() if the form was being used in request scope. > > There are a number of open and unanswered threads about this > on struts-user, > making it a documentation error or a coding error. While the > source is the > ultimate form of documentation, there are many in the field > that use Struts > in commercial environments such as BEA and IBM and are not > used to finding > the answer this way. While I am quite jazzed to get a copy > of Chuck's book > in my hands so I can read something that doesn't flicker at > 70Hz, I dearly > wish that the JavaDocs sufficiently covered the topics so > that the reigning > king of IDEs (IntelliJ IDEA, of course :-) could beam clarity > into my feeble > pea of a brain with the expended effort of typing "shift-F1". > > I'll prepare a patch if required, either for the source or > the docs, but I > wasn't ready to presume that I was in sync with ppl on this. > > Thanks for bearing with me... > > -b > > -- > To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
