looking at the doc for ModelDriven
http://www.opensymphony.com/xwork/api/com/opensymphony/xwork/ModelDriven.htm
l
we see the method
Object getModel()
Returns:
the model to be pushed onto the ValueStack instead of the Action itself
we can now use OGNL to access the model object -without worries about
transfer via dTO and or unsynched map merges
http://struts.apache.org/2.x/docs/ognl-basics.html
When it makes sense to scan for company proprietary code can you publish
your conversation interceptor?
Make Sense?
M--
----- Original Message -----
From: "Gabriel Belingueres" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <user@struts.apache.org>
Sent: Tuesday, March 04, 2008 11:49 AM
Subject: Re: Conversation Scope?
> Well at this point I'm not proposing nothing in particular, just
> trying to understand the rationale behind this relation between
> conversation scope and model driven, which is not clear to me why it
> is designed this way.
>
> I thought that a possible explanation would be to keep the view (JSP)
> pages unaware of the scope of the variables it uses but honesty I'm
> not fully convinced of the gain I can achieve with this practice.
>
> I've developed a conversation scope interceptor I'm using in my
> projects and I don't use modelDriven interface.
>
> ModelDriven interface is (IMHO) uncomfortable because it is designed
> to return only one object for use in the view, which IMO is
> unrealistic but in the simplest use cases. In addition, if you want to
> use several objects in the view, it forces to either create a DTO (not
> good) to reunite all data or using a Map with domain objects but in
> either case you end up with something not very different to not using
> model-driven.
>
> 2008/3/4, Martin Gainty <[EMAIL PROTECTED]>:
> > 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]
> >
> >
>
> ---------------------------------------------------------------------
> 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]
