Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (nike.apache.org: domain of mgainty@hotmail.com designates
 65.54.246.158 as permitted sender)
Message-ID: <BLU136-DAV12DC676ED91940F8660985AE100@phx.gbl>
From: "Martin Gainty" <mgainty@hotmail.com>
To: "Struts Users Mailing List" <user@struts.apache.org>
References: <15648166.post@talk.nabble.com>
 <47C0BFCF.4060305@blueskyminds.com.au> <47C0D50C.3040703@allthisisthat.com>
 <47C18D4D.80402@cyberspaceroad.com> <47C1D735.8040201@allthisisthat.com>
 <47C1D993.5070900@blueskyminds.com.au>
 <cf66e280803040500q559ad22bx15870c80ad4e7321@mail.gmail.com>
Subject: Re: Conversation Scope?
Date: Tue, 4 Mar 2008 08:51:43 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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" <belingueres@gmail.com>
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 <jeromy.evans@blueskyminds.com.au>:
> > 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: user-unsubscribe@struts.apache.org
> > >> For additional commands, e-mail: user-help@struts.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org