Digging deeper into the struts2 architecture I can see now how the ActionErrors
tag is quite a lightweight thing.
I'd rather avoid setting up my own mechanism for handling session usage in an
action superclass as I did with struts1 - I prefer the idea of an interceptor
handling it, but as I implied in my first message, I also like the idea of
having this done automatically with no further configuration in any action xml.
So for the meantime, I'm going to tweak MessageStoreInterceptor for this purpose.
What further scenarios do you see for putting things in the session for
automated transfer to the next request? To my mind, error messages and
informational messages are an important enough component in their own right not
to be bundled up into a more generic mechanism.
I avoid the use of the term 'flash scope'. That's the Spring Webflow term you
are borrowing I guess. Abstracting away from the HTTP paradigm, as 'flash',
'conversation' and the bulk of Spring Webflow mechanisms do, is
counter-productive in the long term unless you are creating a restricted,
RAD-style framework where the user will never need to know details of the HTTP
servlet mechanism. It constantly surprises me when I see colleagues who are
meant to be webapp developers unable to figure out what is going on in the
server-side between the browser and the business tier (I'm disrespecting Spring
Webflow here!).
I see the ActionErrors tag is linked in with the HTML templating mechanism too.
For applications like the one I'm working on where there's no usage of the
templating framework (it's set to 'simple'), it is fortuitous that the 'simple'
template for the errors tag applies exactly the HTML that I need, although I
feel uncomfortable for the future that it locks me in like that.
I hope this comes across as constructive!
Don Brown on 21/09/07 04:43, wrote:
I agree it could be made easier. I'd like to see it combined with a
flash scope-type interceptor so that more than just messages could be
passed via the session automatically.
As for your solution, you could implement the SessionAware interface
and get the session map directly, then you could do whatever you want.
Don
On 9/21/07, Adam Hardy <[EMAIL PROTECTED]> wrote:
From the javadocs, this interceptor seems to have a relatively complicated
configuration that caters for situations over and above what I need relating to
message and error caching when redirects are involved.
A solution to simplify MessageStoreInterceptor would be where it puts the msgs
and errors into the session on one call and automatically switches its state
from STORE to RETRIEVE. On the next request after doing whatever RETRIEVE does,
it could then automatically flip to STORE state.
Would that work?
Another solution would be if the messages and errors are stored in the session
all the time and then removed once they have been displayed, e.g. by the actual
actionmessages or actionerrors tag.
Can I abandon the MessageStoreInterceptor then and somehow tell S2 to put the
actionerrors straight into the session? Then I could extend the taglib to remove
them when displaying them.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
