On Mon, 11 Nov 2002, Martin Cooper wrote:
> Date: Mon, 11 Nov 2002 14:39:51 -0800 > From: Martin Cooper <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: 'Struts Developers List' <[EMAIL PROTECTED]> > Subject: RE: Unclear semantics on form use for "wizards" > > 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? > That's certainly a simple approach. In effect, though, you're still "resetting" the form properties ... to whatever your initialization expressions (or the form bean constructor) sets them to. > 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. > Solves a bunch of other problems, too - including avoiding scalability concerns of memory occupancy between requests, as well as nasty scenarios of multiple simultaneous requests to the same session. > -- > Martin Cooper Craig > > > > -----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> > > -- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
