Hi Gabriel-
are your proposing an enhancement to s:head as i think this concept is
already covered by s:head which sets up global attributes?
http://struts.apache.org/2.0.6/docs/head.html
or a separate "s:conversation" tag ?
M-
----- Original Message -----
From: "Gabriel Belingueres" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Tuesday, March 04, 2008 8:00 AM
Subject: Re: Conversation Scope?
> Why model-driven? I don't fully get it.
> I've done several S2 apps by now and never fell the time to use the
> model driven interface before (for me this is syntax sugar.)
>
> Now why is this important for supporting conversation scope?
> Is it for not writing code like
> ${conversationsMap[conversationId].myproperty} in the view? it is easy
> to create a tag that inject the conversation into a request-scoped
> variable like this:
> <s:conversation var="myconversation"/>
>
> then use ${myconversation.myproperty}
>
> Gabriel
>
> 2008/2/24, Jeromy Evans <[EMAIL PROTECTED]>:
> > I hadn't noticed this was already part of the 2.1.x core and default
stack:
> >
> > http://struts.apache.org/2.x/docs/scoped-model-driven-interceptor.html.
> >
> > I haven't checked the code but it reads the same
> >
> > Ray Clough wrote:
> > > I'm definitely going to have to watch the 'ranting'. (By the way,
> > > Adam, you have to stop grappling with SWF when you get married.)
> > >
> > > It seems to me that 'ModelDriven' is not much use without
> > > ConversationScope, because you have to manually manage the
> > > model/session interaction in all but the first action in the
> > > conversation. What I'm talking about with the term
> > > 'ConversationScope' is the need not to have to explicitly store,
> > > check, and remove my model data from the session in each action.
> > > Basically my action always looks like this:
> > >
> > > 1. check session for model.
> > > 2. if found, is model for the current conversation
> > > * if no delete the model from the session, create new model
> > > and place in session.
> > > * if yes place it into the Action's private variable
> > > 3. ...... whatever the action does .......
> > > 4. is the conversation finished?
> > > * if no, make sure model is in session
> > > * if yes, remove model from session
> > >
> > > This seems like a pretty straight-forward use case for an
> > > interceptor. I'm thinking of a small object called
> > > "ConversationScope", which, of course, has to be stored in the
> > > session. The ConversationScope obj contains a map and a method to
> > > return its ConversationId, and methods to add and remove objects from
> > > its map. The interceptor could do to the ConversationScope the
> > > actions which the Action currently does, as delineated above. It
> > > might be nice to inject the ConversationScope into the action, but I
> > > don't personally know injection well enough to do that. A full
> > > solution with injection should have a "ConversationAware" interface
> > > which includes a "ConversationId" attribute. It might be better to
> > > use annotations rather than an interface declaration.
> > >
> > > I'm just thinking on paper here, but it doesn't seem like any massive
> > > over-architecting is needed. I personally have almost no experience
> > > with Spring, and every time I touch it everything breaks. Guice
> > > sounds like a nicer solution, but there is not much tutorial info on
it.
> > >
> > > Thanks,
> > > - rc
> > >
> > >
> > > Adam Hardy wrote:
> > >> Is it worth building a mechanism for conversation scope, compared to
> > >> the complexity it introduces? I really dislike Spring Webflow with
> > >> its conversation scope, stringent encapsulation and storage of
> > >> massive amounts of data in various maps that locks away everything
> > >> out of sight and makes it all taste like it's been massively
> > >> over-architected (and of course the practically insurmountable
> > >> learning curve)
> > >>
> > >> Isn't it just easier to clean your variables out of the session
> > >> manually when done? I'm not trying to provoke another rant, it's just
> > >> that I've suffered my fair share of pain grappling with SWF and I
> > >> find all justifications of its complexity unwarranted.
> > >>
> > >> Adam
> > >>
> > >> Ray Clough on 24/02/08 02:23, wrote:
> > >>> Thanks Jeromy. (usually my wife is the only one who notices my
> > >>> 'rants').
> > >>>
> > >>> Jeromy Evans wrote:
> > >>>> Hi Ray,
> > >>>>
> > >>>> I'm not sure, but check out Tom's new scope plugin as it may get
> > >>>> you part of the way there.
> > >>>>
> > >>>> http://cwiki.apache.org/S2PLUGINS/scope-plugin.html
> > >>>>
> > >>>> I was just reading one of your rants from August 07 that mentioned
> > >>>> the need to use ModelDriven's model across a conversation and think
> > >>>> this will be useful.
> > >>>>
> > >>>> cheers,
> > >>>> Jeromy Evans
> > >>>>
> > >>>> Ray Clough wrote:
> > >>>>> JSF has a "ConversationScope" for extended series of
> > >>>>> requests/responses
> > >>>>> dealing with the same topic, and usually the same data model. I'm
> > >>>>> thinking
> > >>>>> of writing an interceptor to simulate ConversationScope, and I'm
> > >>>>> wondering
> > >>>>> if this has not already been done, and if so, does anyone have
> > >>>>> details,
> > >>>>> code, etc.
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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]
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
