Thanks. That helps. One thing puzzles me, though, as to how others handle this specifically with regards to Struts. Does this mean that those that use the session scope simply manage the reset action very carefully? And how does the reset action not get called in situations where you want to retain the data?
I guess I've always used request, so I've never developed Struts in this manner. I'm not really sure what the least sloppy way to go about handling a session scoped form bean would be, to be honest. Preston >>> [EMAIL PROTECTED] 10/26/2005 9:50:24 PM >>> Please, read this short intro: http://struts.sourceforge.net/strutsdialogs/#traditionalflow It advertises Struts Dialogs library (doh), but also explains where the power of session scope and two-way request processing is. Also read about JSF and Wicket. Wicket developers use two-phase request processing as a cornerstone of the request lifecycle. But they went further: on the input phase they render a result page into a stream and push it to session, at this point they can detach database connections and such. Then they redirect to the address, which pops the stream from the session and renders a page. Nice. JSF by default uses session scope because it is easier to handle data in the backing bean between requests. Also, you would need to store some data between requests anyway, why not to put all action-related data to one object, an ActionForm, instead of queueing it to session object or request object. The main issue with session scope is automatic disposal of unneeded objects (garbage collection). I don't know how this is implemented in JSF. Wicket uses configurable cache, 10 pages by default. There is a Web Flow Navigation Manager, which can help to control session size in Struts. The similer technology will be included into next version of Struts Dialogs. Michael. On 10/26/05, Preston CRAWFORD <[EMAIL PROTECTED]> wrote: > I don't know why (I've been doing struts development for years, but I > guess we've always been very explicit in our struts-config files), but > only recently did I discover that this was the default behavior for form > beans. And I'm trying to figure out, mostly on a higher level, on a > theoretical level this is this way. I'd like to understand what is it > about session scope that's preferrable as a framework. Not being > judgemental. Just curious if we're missing the boat by using request > scope most of the time and session some of the time. I know some other > frameworks like Tapestry make heavy use of the session. So I'm wondering > if there's just something understood about web frameworks that putting > everything into session scope is "better" and the user is meant to sort > out resetting the form or if this was a choice made by the Struts team > for other reasons. > > Preston --------------------------------------------------------------------- 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]
