As Craig mentioned, reset is always called before an autopopulation event. For consistency, it is also called if the html:form tag needs to instantiate the form itself.

In a multi-action sequence, the request is run through the same gauntlet each time. A forwarded request within the container is not treated any differently than a new request from a client. So, as mentioned, you have to be careful about the resets.

In general, you only need to reset checkboxes when a form is in session scope. People tend to reset other properties as well, but that generally serves no purpose, since they will be overwritten anyway.

In Jerry's case, he indicated reset was being called when forwarding directly to a JSP. Since the request for a *.jsp would not pass through the ActionServlet, the only other way for reset to be called would be if the ActionForm is being instantiated by the html:form tag.

-Ted.


Paul Harrison wrote:
I have looked at this again, and in 1.1 rc2 on tomcat 4.1.18 the reset is called for each action of a multi action sequence sharing a form bean even though the form bean is in session scope and only created once - I have written a demo app with logging that shows this behaviour - should I submit a bug if this is not what is intended to happen.

Paul.

Paul Harrison wrote:

I am writing an application with a series of "wizard" type pages, so I thought that I would use one big ActionForm in session scope and each page add extra information to it - however this did not work as reset was being called at each page invocation - I am interested to hear that reset should only be called at instantiation time, because I believe that in 1.1 RC2 it is being called more often than that - I can did out the old verision of the code to have a look at the exact circumstances if necessary....

Ted Husted wrote:

In Struts 1.0.2 and later, reset is called by the html:form tag *if* the ActionForm is being instantiated at that time. The scope shouldn't matter.

Also remember that the html:form tag is looking at the Action to which it submits, which may not be "Action 1". If these are the same Action, or share the same formbean under the same attribute, then the ActionForm should already exist, and reset should not be called.

-Ted.

Jerry Jalenak wrote:

I'm seeing some odd behaviour with one of my actions. If anyone can explain
this I'd sure appreciate it....


Here's what I've got - in struts-config I have an ActionForm that is shared
by two Actions. The ActionForm is created in session scope by the first
action, and referenced by the second Action (also in session). Tracing the
calls to 'reset' and 'validate' I see the following:


    JSP is displayed  -> html form is submitted -> 'reset' is called ->
'validate' is called -> Action 1 is performed -> forward to next JSP ->
'reset' is called -> JSP is displayed
    /\/\/\/\/\/\/\ !

My understanding is that 'reset' should not be called again until the form
on the second JSP is submitted. Have I completely mis-understood how this
works? Or is it something due to the ActionForm being created in session
scope?


TIA!

Jerry Jalenak
Team Lead, Web Publishing
LabOne, Inc.
10101 Renner Blvd.
Lenexa, KS  66219
(913) 577-1496

[EMAIL PROTECTED]


This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at the following email address: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to