AFAIK the model is pushed onto the stack *in addition* to the action. I don't know of anywhere in the docs where it states that the action would be unavailable.
Dave --- Roberto Nunnari <[EMAIL PROTECTED]> wrote: > Hi. > > About the ModelDriven interface.. I believe I'd read somewhere > that when you implement it, your view looses access to the action.. > > ..but using it I found out that if the method/property is not > found in the model, then at some point the action is searched > for it.. so with that in mind, you can access multiple objects > from your view. > > But now I doubt that if the doc somewhere says that the action > will not be accessible when implementing the ModelDriven interface, > someday updating my webapp to a newer version of S2 I'd meet > a bad surprise.. > > any thoughts here? > > Robi > > > Gabriel Belingueres wrote: > > 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] > === message truncated === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
