On 3/22/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> On 3/22/06, Mark Lowe <[EMAIL PROTECTED]> wrote:
> > On 3/22/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
> > > On 3/22/06, Mark Lowe <[EMAIL PROTECTED]> wrote:
> > > > For data you need to store across lots of requests, you can create a
> > > > simple javaclass to hold the data you need. Something like a StateBean
> > > > or even a hashmap, the point is that if you have one object that your
> > > > storing things in you know where to look if and when you find you need
> > > > to address session size. If you have folk adding the world into the
> > > > session all over the place, its going to be harder to address any
> > > > issues later in the day. e.g. Map state = (Map)
> > > > session.getAttribute("state")
> > >
> > > Such holder class is already provided by Struts for every action. It
> > > is called ActionForm ;) I stick all my action-related... I mean,
> > > webresource-related :) stuff into corresponding ActionForm.
> >
> > If its the from you want in the session, you wont hear any arguements
> > from me there. But its also possible that the data you need to store
> > isn't really a form, you may need to populate a form with some session
> > scoped data (yes it could well be an action form). You may want to
> > reset a form but not the session scoped gubbins. One example i can
> > think of is maintaining the state of a gui, selected items and such
> > like. I never have a real need to have this data mapped to an action.
>
> This data is not mapped to an action, it belongs to a web resource. An
> action (or several actions) handle requests to a web resource, while
> ActionForm holds state of a web resorce. Instead of fixating on
> actions try to concentrate on an ActionForm ;)Its not a fixation, and like I said I have sympathies with using an action form for this. But recently I had to get someone up and started with struts comming in from the cold, and quirks like this can confuse folk. Albeit a rumination I think that a session scoped form needs mapping to an action to be initially instantiated. If Struts had Action > and ActionForm as one class, things would be easier. > > I don't care that ActionForm was originally intended to hold request > values. I use it as a web resource state holder and stick all kind of > resource-related stuff into it. Works great for me, all in one place, > accessible. I can also make use of Struts automatic population of > nested properties. Population of indexed properties is a nice gift, but then I cant think of many situations where needing to scope anything that extreme is required. A bean with simple properties will do <jsp:useBean id="state" class="foobar.State" scope="session" /> <jsp:setProperty name="state" property="*" /> takes care of any simple properties, and if you dont like doing this stuff in jsps then in the execute method of a base action will do just as well. If stuff works for you then thats great, but while I believe using session when something else cant be done in a clear and readable way. I just dont see the point in giving a container a bad day when it needs to serialize these objects, the same way as i dont think bending over backwards to avoid using the session is worth it either. Another consideration is the increased popularity of xmlhttprequest to have the client make requests, if a front end updates from the server at any intervals. All you need is are users leaving a browser window open to increase the amount of active sessions on the container. Of course something that listens where there are any events on the active window could log the user out in his/her absence, but already its less simple than just timeout configuation. Again, I'm not disagreeing with you, in some situations I can see what you're saying being clean and low risk, I just dont think all the time. Mark > > Michael. > > --------------------------------------------------------------------- > 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]
