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]
