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>
