Mark and all, I was working on the View chapter today and I noticed that reset() is called on an ActionForm, regardless of the scope. This is done at the very end of the createActionForm() method in the RequestUtils. The createActionForm() method is called for every request in the processActionForm() method of the RequestProcessor.
I was just wondering about that and whether this is intended for some reason or possibly a bug. Maybe the reset should only be called if the scope = "request"? Chuck At 11:27 AM 5/18/2002 -0400, you wrote: >Ted/Craig, > >Speaking of states (like the insane one I find myself in, being in the >office on yet another Saturday :-( ), the spec allows the specification of >scope for an ActionForm in struts-config.xml but I've found it has no >effect. For example, I specify an form bean in session scope, but all the >properties get reset to defaults after every "pass through" by the Action. >The only way I've found to maintain the bean's state is removing the body of >reset() in the bean and providing only a call to super.reset( mapping, >request ). > >I'll be testing my app with multiple clients soon, but what I'm not clear on >now is how Struts handles beans in session scope with respect to different >simultaneous clients. Does ActionServlet create a pool of stateless beans >to serve each client, or are multiple clients going to see the state of the >bean previously set by a separate client? My understanding is that the >Action uses one instance of a bean like a singleton, resetting its >properties before releasing it to service another thread. If this is >correct, what exactly is happening if the bean is declared in session scope >and/or the reset() is stripped? > >Mark > >-----Original Message----- >From: Ted Husted [mailto:[EMAIL PROTECTED]] >Sent: Saturday, May 18, 2002 7:59 AM > >The properties in the ActionForm aren't states but ~prospective~ states. > >After the input is validated, then it can be converted (and perhaps >transformed) to an actual state. > >The underlying problem is that HTML controls have no input buffer. There >is no place to store whatever claptrap people might enter into a field >-- except in an ActionForm. Just because they enter "a1" into a field >that doesn't make it a valid state for that field. > >ActionForms are also a firewall. Most Web applications are living in >hostile environments. Even if you use JavaScript validation on your >form, there is no guarantee that a hostile will use it. CGI accepts >input first -- ActionForm ask questions later. > >Finally, ActionForms often represents many presention-states that are >not present elsewhere in the application. This gives you a place where >you can have everything you need to handle an input request in one >place. > >For more see, > >http://jguru.com/forums/view.jsp?EID=811382 > >-- Ted Husted, Husted dot Com, Fairport NY US > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
