> >The reason this is implemented this way is that ActionContext's are > >created and set in only the one place... Therefore there can only be > >the previous ActionContext and the new ActionContext... > > What about a Sitemesh decorator default.jsp and its child > *.jsp(s)? Or > nested tiles of *.jsp(s)? Could they have their own actions > that upon > return would need the old Action restored? > At 11:53 AM 9/28/2003, Jason Carreira wrote: The old Action is restored now... What do you mean?
If I am reading the code correctly, you do have an n-level stack now, not just a previous ActionContext and a new one. The ActionProxy contains the previous ActionContext which has an ActionProxy which has the previous ActionContext... Its just that the ActionProxy should probably not be acting as a node in the linked list of a stack implementation. If as Mike intimates, that ActionInvocation is actually the component that should be handling ActionContext manipulation, it seem counter-intuitive to have the stack state, a level above the manipulator instead of inside the ActionContext. That is all.
On the Sitemesh comment, Sitemesh executes as a Filter which executes prior to the ServletDispatcher. If it had used an ActionTag, would it not have created an ActionContext associated with the thread? I do not see where the ActionContext is reset, in a SerlvetDispatcher or elsewhere. So if .jsp(s) using Actions contain .jsp(s) (as in Sitemesh and Tiles) which use new Actions, each of which change the ActionContext, it would be good to have the ActionContext restored on return to the parent .jsp. Which is what you have now (I believe), just kind of a weird stack.
And hey, if I am misreading how the whole ActionContext is an n-level stack, let me know.
Fred.
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
