<snip> My recommendation is to *always* use request scope form beans if you can. </snip>
Yes. Having done it both ways and experiencing the various tortures that session scoping inflicts apon us I would definately agree that if one can use the request scope (and with a little thought this should be possible in most situations) then do so. It eliminates so many hassles. That said, I do have a small minority of forms in one of the apps I did that could be in request but arent - the reason being most of the forms need session scope (see below) and they all share a ton of common code in the actions and renderers superclasses - and being able to make the same assumptions and reuse the same code makes life simpler rather than making special exceptions for those forms. <snip> The only reason a form bean should ever be in session scope is if you want it to preserve values across requests that are not included in the form on the current page. </snip> There are two things I am doing with session scope that would be quite hard to do with request scope and they meet this criteria. (Well three if you include tab-panes, but if one drops support for netscrap6 then they can be done with css hiding now) The first is supporting multi-file fields. (Fields that allow uploading of n files). In this case we need somewhere to put those files or at least info about them (ie: session) until such time as the user has both finished adding files to the file fields on the form, and has also passed form validation. At which point we can finally process these files (for our apps this usually involves just persisting them somewhere.) It is imho (and more importantly in potential customers opinions too) quite unacceptable to force the user to re-upload all fifty billion huge files (a slight exageration) every time they make a typo or forget to fill in some other field on the form. I would think however that this wont play well with clustering (though one could write the files temporarily to a db instead of directly in the session I suppose). (Actually one can code this so that the form is request scoped and one only needs to keep the file manager object thingy in session (and pass its key in the request), but often the form only has a few other fields and its just easier to do it this way) The second thing that I use the session to support is what I call 'diversion'. The app I use this technique in is rather complex. There are several dozen different types of records that can be configured from the UI and most of them have references to other records of other types (foreign keys). Often times one is halfway through configuring one of these records when one realises that one has yet to configure the record it depends on (and the record the record it depends on depends on, etc... ad infinitum). The 'diversion' technique allows the user to divert off to create/edit the associated record without having to either abandon the record they are currently editing (its incomplete so they cant 'save/commit' it as it wont pass validation) or go back to the main window and navigate through the various views to the other records list to popup an edit form for the other record. Instead they simply click a diversion link ( a wee little arrow icon ) next to the select box and are whisked straight off to the edit form for the other record in the current window (either in create or edit mode depending on whether an instance was selected in the select box on the previous screen). They can create or edit the required record (including further diversions for its own dependencies) and once they save it (or cancel) they are returned back to the previous form in the operation stack with all values already input and files uploaded preserved as it was when they diverted. (I actually first came up with this in a vain attempt to try and avoid the need for popups but they were added to the requirements anyway, and in hindsight have made the app a lot more user friendly with both popups and diversions (which are rather like wizards in their ability to guide the user to things that need doing) being supported. Have had a fair bit of positive feedback about it when compared with an earlier swing based version of the app that didnt have this feature - so while its a nuisance to code the payoff is in higher user satisfaction) Since configuring a new installation of the app can involve setting up a lot of records (this aint no 3 form shopping cart) and remembering what needs to be set up in what order and how it all relates can be hard, this diversion mechanism has proved quite popular, and has made it a lot quicker to setup a new installation of the application, or to reconfigure an existing installation. Now I wouldnt recomend this technique for a high traffic public website that gets huge hitcounts, but for an _application_ that is (usually) accessed by intranet by a relatively small number of simultaneous users, and where the complexity of the application is high (and a simpler ui design would reflect this complexity by being hard to manage for the user), it works quite well to help keep things simple for the users and makes using the app a lot easier. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Sunday, 15 February 2004 03:12 To: Struts Users Mailing List Subject: RE: [OT] - Request against Session Quoting Michael McGrady <[EMAIL PROTECTED]>: > > >Now let us assume that the ActionForm for the record editing form needs to > >go in session scope (nb: in request scope there is not a problem so if the > >design can be done practically with request scope that is much better). > > > Hi, Andrew, > > Now this is becoming interesting. Let's talk about this decision. If we > are taking data from a view, wouldn't it be paramount to make sure that the > what we got was from that view alone? What possible benefit would there be > to putting the ActionForm into session scope? > The only reason a form bean should ever be in session scope is if you want it to preserve values across requests that are not included in the form on the current page. An example use case would be a wizard dialog that is composed of multiple pages, all updating the same form bean but containing different subsets of the fields. My recommendation is to *always* use request scope form beans if you can. Most of the reasons you might like to use session scope can be dealt with in other ways -- for example, the wizard dialog scenario can be addressed by simply including hidden input fields for all the fields that are not displayed on the current page of the wizard. > Michael Craig McClanahan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
