Re: Small Complaint - Struts Impl.
The only time reset() is of direct value to the framework is when * the form is being maintained in session scope, AND * there are boolean properties on the ActionForm In practice, using reset() to return all values to their initial state is usually either futile or problematic. It's futile when the bean is in request scope since a new bean's properties will be at their initial state. It's problematic for non-boolean properties since they may have values you'd like to retain. In most cases, developers probably want to include a mutable and a page property on their ActionForms. Mutable can be used to tell the property mutators NOT to access any new values (mutable=false). This is very useful when forwarding ActionForms between Actions in the same request. The reset()/automatic-population guantlet takes place on every trip through the ActionServlet which can happens more than once in a request. A page property (like the one provided by ValidatorForm) can be very useful in wizard forms. The various properties can be reset according to what page they are on. If page=0 then all values can be reset(). Otherwise, you can reset values (including the booleans) according to what page of the wizard they are on. (Not an ideal wizard-solution, but I don't know if we have an ideal solution yet.) A WORM ActionForm, like Craig mentioned, can also be useful. Here the mutator checks to see if its value is NULL before setting it again. This is much like having a mutator switch but without the bother of turning it on and off. Regarding how ActionForms behave in different scopes, it's important to remember is that whether clients share a session is really up to the clients. The sessions are usually determined by cookies, and the clients determine whether the cookies (and ergo the session) are stored. If two clients manage to share a cookie (or page with a rewritten URL), they will share whatever is in the session. Struts has no say in the matter. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Galbreath, Mark 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 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Small Complaint - Struts Impl.
Not strictly true, we use the form reset method to prepare complex forms from an xml description, although it is a bit messy as reset is called too often. we end up looking for size properties from the request and if we don't find the attributes then just continue, we will eventually be called with the right information. What we need on forms I believe is some other functions on form ... void prepare( ActionMapping, HttpServletRequest ) - called before the form is populated from the request. Allows the form to create any data structures required to allow population to take place. void fill( ActionMapping, HttpServletRequest ) - Allow a form to load any lookup information. Called automatically if form validation fails, before forwarding the form back to the input jsp. Useful when you say have an id of something on the form which is from a dropdown selection objects. Would be called manually from the code that sets up the form. Ian [EMAIL PROTECTED] 05/20/02 12:43pm The only time reset() is of direct value to the framework is when * the form is being maintained in session scope, AND * there are boolean properties on the ActionForm In practice, using reset() to return all values to their initial state is usually either futile or problematic. It's futile when the bean is in request scope since a new bean's properties will be at their initial state. It's problematic for non-boolean properties since they may have values you'd like to retain. In most cases, developers probably want to include a mutable and a page property on their ActionForms. Mutable can be used to tell the property mutators NOT to access any new values (mutable=false). This is very useful when forwarding ActionForms between Actions in the same request. The reset()/automatic-population guantlet takes place on every trip through the ActionServlet which can happens more than once in a request. A page property (like the one provided by ValidatorForm) can be very useful in wizard forms. The various properties can be reset according to what page they are on. If page=0 then all values can be reset(). Otherwise, you can reset values (including the booleans) according to what page of the wizard they are on. (Not an ideal wizard-solution, but I don't know if we have an ideal solution yet.) A WORM ActionForm, like Craig mentioned, can also be useful. Here the mutator checks to see if its value is NULL before setting it again. This is much like having a mutator switch but without the bother of turning it on and off. Regarding how ActionForms behave in different scopes, it's important to remember is that whether clients share a session is really up to the clients. The sessions are usually determined by cookies, and the clients determine whether the cookies (and ergo the session) are stored. If two clients manage to share a cookie (or page with a rewritten URL), they will share whatever is in the session. Struts has no say in the matter. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Galbreath, Mark 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 -- 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]
Re: Small Complaint - Struts Impl.
I should have clarified that when I said of value to the framework, I meant the framework proper, not necessarily as reset() might be extended by a particular application. Some developers do use reset() to perform any number of customizations -- but that is not why it exists from the framework's POV. In 1.1 beta, there is a processPopulate() hotspot where you should be able to experiment this type of functionality, and if it works out, don't hestitate to report back to the list. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Ian Tomey wrote: Not strictly true, we use the form reset method to prepare complex forms from an xml description, although it is a bit messy as reset is called too often. we end up looking for size properties from the request and if we don't find the attributes then just continue, we will eventually be called with the right information. What we need on forms I believe is some other functions on form ... void prepare( ActionMapping, HttpServletRequest ) - called before the form is populated from the request. Allows the form to create any data structures required to allow population to take place. void fill( ActionMapping, HttpServletRequest ) - Allow a form to load any lookup information. Called automatically if form validation fails, before forwarding the form back to the input jsp. Useful when you say have an id of something on the form which is from a dropdown selection objects. Would be called manually from the code that sets up the form. Ian [EMAIL PROTECTED] 05/20/02 12:43pm The only time reset() is of direct value to the framework is when * the form is being maintained in session scope, AND * there are boolean properties on the ActionForm In practice, using reset() to return all values to their initial state is usually either futile or problematic. It's futile when the bean is in request scope since a new bean's properties will be at their initial state. It's problematic for non-boolean properties since they may have values you'd like to retain. In most cases, developers probably want to include a mutable and a page property on their ActionForms. Mutable can be used to tell the property mutators NOT to access any new values (mutable=false). This is very useful when forwarding ActionForms between Actions in the same request. The reset()/automatic-population guantlet takes place on every trip through the ActionServlet which can happens more than once in a request. A page property (like the one provided by ValidatorForm) can be very useful in wizard forms. The various properties can be reset according to what page they are on. If page=0 then all values can be reset(). Otherwise, you can reset values (including the booleans) according to what page of the wizard they are on. (Not an ideal wizard-solution, but I don't know if we have an ideal solution yet.) A WORM ActionForm, like Craig mentioned, can also be useful. Here the mutator checks to see if its value is NULL before setting it again. This is much like having a mutator switch but without the bother of turning it on and off. Regarding how ActionForms behave in different scopes, it's important to remember is that whether clients share a session is really up to the clients. The sessions are usually determined by cookies, and the clients determine whether the cookies (and ergo the session) are stored. If two clients manage to share a cookie (or page with a rewritten URL), they will share whatever is in the session. Struts has no say in the matter. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Galbreath, Mark 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
RE: Small Complaint - Struts Impl.
I've done the same thing with handling logins, but I put a stack in the session that stores request tokens, so I can keep forwarding the user elsewhere and just keep popping the requests off the stack as form tasks are completed (essentially rollbacks) -Original Message- From: Tim Sawyer [mailto:[EMAIL PROTECTED]] Sent: Sat 5/18/2002 1:08 PM To: Struts Users Mailing List Cc: Subject: RE: Small Complaint - Struts Impl. On Sat, 2002-05-18 at 16:52, Craig R. McClanahan wrote: It is the third rule that is the most likely cause for problems, especially if you are using a single form bean to capture the data from multiple pages (such as in a wizard dialog) -- which is about the only time that using form beans in session scope really makes any sense anyway. I'm using form beans in session memory because if the user returns to a page I still want the data they have already entered to be displayed back to them, even though I have already successfully processed that data already on their first run through. Would you suggest a different approach? Tim. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] winmail.dat Description: application/ms-tnef -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Small Complaint - Struts Impl.
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 -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services Jacob Hookom wrote: Is it just me, or on large projects do you find yourself duplicating the same object states for 3 different Action objects? An example would be a creating an Address object that mirrors a row in the DB, then if you want to do an ActionForm, you have to duplicate the states all over again. Ideally, it would be nice to define realm objects once in a config and then just have struts be able to handle the single definition; thereby pairing the DB implementation and Java closer by a single XML file. DynaForms are a step in the right direction, but nothing yet application wide Maybe it should be my summer project ;-) Jake Hookom University of Wisconsin, Eau Claire --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002 -- 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]
RE: Small Complaint - Struts Impl.
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]
RE: Small Complaint - Struts Impl.
This throws a kink in some of my bean implemenations Start Quote from Action.java: Actions must be programmed in a thread-safe manner, because the controller * will share the same instance for multiple simultaneous requests. In * this means you should design with the following items in mind: * ul * liInstance and static variables MUST NOT be used to store information * related to the state of a particular request. They MAY be used to * share global resources across requests for the same action./li * liAccess to other resources (JavaBeans, session variables, etc.) MUST * be synchronized if those resources require protection. (Generally, * however, resource classes should be designed to provide their own * protection where necessary./li -Original Message- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 18, 2002 10:27 AM To: 'Struts Users Mailing List' Subject: RE: Small Complaint - Struts Impl. 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] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.351 / Virus Database: 197 - Release Date: 4/19/2002 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
Mark wrote: 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? As I understand it, Session scope is in a memory pool specific to a particular client session, so if you create form beans in session memmory (as I do) then the data in those beans is only ever able to be seen by that particular client session, never any other session. I don't use reset() either, it doesn't make sense if you're putting stuff in session scope. Tim. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
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]
RE: Small Complaint - Struts Impl.
On Sat, 18 May 2002, Galbreath, Mark wrote: Date: Sat, 18 May 2002 11:27:15 -0400 From: Galbreath, Mark [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: Small Complaint - Struts Impl. 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 ). If you are resetting evertying to defaults in your reset() method, that is exactly what you should expect. Struts calls reset() before it populates the form bean properties, on every request -- so, if you have your form bean in session scope, you'll only want to reset properties that are present on the current page (and will thus get repopulated with their current values). 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? Although Action instances are singletons, form beans are not. Form beans placed in request scope are instantiated on every request, while form beans placed in session scope are created only if they are not in session scope already. After that decision, form beans are treated identically, no matter which scope they are in. In particular, reset() is called on every request. Mark Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
That's my feeling as well, Tim. I asked Craig about this a few weeks ago and based on (probably my misunderstanding of) his response, I synchronized all the mutators and accessors in the bean. Since it's session scoped, I don't think this is a performance issue, but I also think it's unnecessary. Especially since I have the relevant associated blocks in my Action class synchronized. Like you, I thought reset() for a session bean was pointless and though I kept the method because I was not sure if ActionServlet would blow up without it, I made it impotent. Mark -Original Message- From: Tim Sawyer [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 18, 2002 1:23 PM As I understand it, Session scope is in a memory pool specific to a particular client session, so if you create form beans in session memmory (as I do) then the data in those beans is only ever able to be seen by that particular client session, never any other session. I don't use reset() either, it doesn't make sense if you're putting stuff in session scope. Tim -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
On Sat, 18 May 2002, Chuck Cavaness wrote: Date: Sat, 18 May 2002 12:30:38 -0400 From: Chuck Cavaness [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: RE: Small Complaint - Struts Impl. 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? The basic reason reset() exists in the first place is to deal with boolean properties (typically displayed as a checkbox). The problem is in the way that HTML form submits work -- if the checkbox is checked, you get the request parameter and Struts can mark the corresponding property as true. However, if the checkbox is not checked, you get nothing at all. So, what should Struts do with boolean properties on your form bean? Now, Struts could use reflection on your form bean and assume that all the boolean properties need to be flipped back to false before checking the request parameters, but that seems somewhat presumptuous. Instead, Struts calls reset() and leaves it up to the form bean implementation to decide what to do. But, now, you should be able to see why it should be called on every request, even if the form bean is in session scope, right? A way to think about the contract you should implement for reset() is: * Reset *all* boolean properties that correspond to checkboxes on the current form to false. * Optionally, reset any other properties that appear on the current form -- for example, if an input field is conditionally rendered and might not be present on the input request. * Do not touch *any* property that is not present on the current form. It is the third rule that is the most likely cause for problems, especially if you are using a single form bean to capture the data from multiple pages (such as in a wizard dialog) -- which is about the only time that using form beans in session scope really makes any sense anyway. (Chuck, if you can get this concept across clearly in your book, you will save untold numbers of new Struts developers a *lot* of grief :-) Chuck Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
On Sat, 2002-05-18 at 16:42, Galbreath, Mark wrote: That's my feeling as well, Tim. I asked Craig about this a few weeks ago and based on (probably my misunderstanding of) his response, I synchronized all the mutators and accessors in the bean. Since it's session scoped, I don't think this is a performance issue, but I also think it's unnecessary. I'd agree, you don't need to do this. Especially since I have the relevant associated blocks in my Action class synchronized. I can't see offhand why you would need this, can you explain further? Like you, I thought reset() for a session bean was pointless and though I kept the method because I was not sure if ActionServlet would blow up without it, I made it impotent. I have a superclass which overrides reset and then calls an onReset() abstract method, which netbeans creates in each concrete action for me. I just leave this generated code blank most of the time. Tim. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
On Sat, 2002-05-18 at 16:52, Craig R. McClanahan wrote: It is the third rule that is the most likely cause for problems, especially if you are using a single form bean to capture the data from multiple pages (such as in a wizard dialog) -- which is about the only time that using form beans in session scope really makes any sense anyway. I'm using form beans in session memory because if the user returns to a page I still want the data they have already entered to be displayed back to them, even though I have already successfully processed that data already on their first run through. Would you suggest a different approach? Tim. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
Because the bean is in session scope, I don't think it's necessary either. I was going by the API documentation early on (imagine that - RTFM, me?) which isn't too clear on when synchronization is required, but is sufficiently scary that I did it anyway. :-) -Original Message- From: Tim Sawyer [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 18, 2002 1:54 PM On Sat, 2002-05-18 at 16:42, Galbreath, Mark wrote: Especially since I have the relevant associated blocks in my Action class synchronized. I can't see offhand why you would need this, can you explain further? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
On Sat, 18 May 2002, Galbreath, Mark wrote: Date: Sat, 18 May 2002 12:42:56 -0400 From: Galbreath, Mark [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: Small Complaint - Struts Impl. That's my feeling as well, Tim. I asked Craig about this a few weeks ago and based on (probably my misunderstanding of) his response, I synchronized all the mutators and accessors in the bean. Since it's session scoped, I don't think this is a performance issue, but I also think it's unnecessary. Especially since I have the relevant associated blocks in my Action class synchronized. Like you, I thought reset() for a session bean was pointless and though I kept the method because I was not sure if ActionServlet would blow up without it, I made it impotent. See previous responses regarding reset(). However, a remark about the need for synchronization ... One of the really nice things about form beans in request scope is that you basically don't have to worry about thread safety -- a new form bean gets created for you on each request, and it's thrown away at the end. In between, no thread other than the one processing this request has access to it, so you can basically pretend (for the form bean) that threads to not exist. When using session scope form beans (or, more generally, any session scope attributes), you *do* have to be concerned about the case where the same user (therefore accessing the same session) might be accessing the same form bean on more than one thread at the same time. But how can that possibly happen? you might ask. Consider the following three scenarios: * You are using frames in your presentation. Most browsers will fire off multiple simultaneous requests to fill up the frame contents, and they will all be accessing the same session. * Your user submits a request that takes a long time to process, but gets impatient -- he or she presses Stop and then submits the page again. (Haven't *you* ever done that to a webapp that is responding slowly? :-). * Your user opens two windows and accesses the application from both of them. Depending on how your browser works, the two windows will usually be in the same session, and you will have to deal with the possibility that he or she might access the same form (and therefore the same session-stored form bean instance) from both windows at the same time. As you can see, session-based form beans can cause you some grief ... besides the memory consumption issues, which is the primary reason that most people try to avoid them. On the good news side of the equation, though, you *still* might not need to synchronize things. For example: * The container is responsible for making sure that things like session.setAttribute() work correctly, even in the face of multithread access. * If your underlying form bean property is a Java primitive or a String, you generally don't need to worry about synchronizing the setFoo() method -- the assignment statement that executes inside the setter either runs or it doesn't. The basic rule for synchronizing mutators is that you need to protect blocks of code that need to run all at once, without interference from any other thread. For example, if you call put() on a HashMap (which is not internally synchronized), as the method runs it will likely, at certain points in time, have the map in an internal state that, from the viewpoint of a different thread accessing it (such as doing a get()) is not correct. For that reason, having to synchronize setters usually means you need to synchronize getters as well, but that is a different issue ... Mark Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Small Complaint - Struts Impl.
Exactly what I'm doing as well. -Original Message- From: Tim Sawyer [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 18, 2002 2:09 PM To: Struts Users Mailing List Subject: RE: Small Complaint - Struts Impl. On Sat, 2002-05-18 at 16:52, Craig R. McClanahan wrote: It is the third rule that is the most likely cause for problems, especially if you are using a single form bean to capture the data from multiple pages (such as in a wizard dialog) -- which is about the only time that using form beans in session scope really makes any sense anyway. I'm using form beans in session memory because if the user returns to a page I still want the data they have already entered to be displayed back to them, even though I have already successfully processed that data already on their first run through. Would you suggest a different approach? Tim. -- 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]
RE: Small Complaint - Struts Impl.
This has been an excellent thread (pun intended), Craig. Thanks for the knowledge transfer! -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 18, 2002 1:10 PM On Sat, 18 May 2002, Galbreath, Mark wrote: Date: Sat, 18 May 2002 12:42:56 -0400 From: Galbreath, Mark [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: Small Complaint - Struts Impl. That's my feeling as well, Tim. I asked Craig about this a few weeks ago and based on (probably my misunderstanding of) his response, I synchronized all the mutators and accessors in the bean. Since it's session scoped, I don't think this is a performance issue, but I also think it's unnecessary. Especially since I have the relevant associated blocks in my Action class synchronized. Like you, I thought reset() for a session bean was pointless and though I kept the method because I was not sure if ActionServlet would blow up without it, I made it impotent. See previous responses regarding reset(). However, a remark about the need for synchronization ... One of the really nice things about form beans in request scope is that you basically don't have to worry about thread safety -- a new form bean gets created for you on each request, and it's thrown away at the end. In between, no thread other than the one processing this request has access to it, so you can basically pretend (for the form bean) that threads to not exist. When using session scope form beans (or, more generally, any session scope attributes), you *do* have to be concerned about the case where the same user (therefore accessing the same session) might be accessing the same form bean on more than one thread at the same time. But how can that possibly happen? you might ask. Consider the following three scenarios: * You are using frames in your presentation. Most browsers will fire off multiple simultaneous requests to fill up the frame contents, and they will all be accessing the same session. * Your user submits a request that takes a long time to process, but gets impatient -- he or she presses Stop and then submits the page again. (Haven't *you* ever done that to a webapp that is responding slowly? :-). * Your user opens two windows and accesses the application from both of them. Depending on how your browser works, the two windows will usually be in the same session, and you will have to deal with the possibility that he or she might access the same form (and therefore the same session-stored form bean instance) from both windows at the same time. As you can see, session-based form beans can cause you some grief ... besides the memory consumption issues, which is the primary reason that most people try to avoid them. On the good news side of the equation, though, you *still* might not need to synchronize things. For example: * The container is responsible for making sure that things like session.setAttribute() work correctly, even in the face of multithread access. * If your underlying form bean property is a Java primitive or a String, you generally don't need to worry about synchronizing the setFoo() method -- the assignment statement that executes inside the setter either runs or it doesn't. The basic rule for synchronizing mutators is that you need to protect blocks of code that need to run all at once, without interference from any other thread. For example, if you call put() on a HashMap (which is not internally synchronized), as the method runs it will likely, at certain points in time, have the map in an internal state that, from the viewpoint of a different thread accessing it (such as doing a get()) is not correct. For that reason, having to synchronize setters usually means you need to synchronize getters as well, but that is a different issue ... Mark Craig -- 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]
