Fred, Once we get the new ActionTag changed around (so that the old valuestack is available to the action while it's executing), try it out and let us know if things still aren't to your liking.
I actually don't fully understand why stuff isn't working for you currently (maybe you could email me a sample bit of code to demonstrate it, based off of the examples in CVS). But I know that we made a conscience decision to make ActionTag work like it does rather than the way it did in the 1.3 due to an effort to greatly simplify the whole operation. -Pat ----- Original Message ----- From: "Frederick N. Brier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, September 28, 2003 3:49 PM Subject: RE: [OS-webwork] ActionTag wipes out own ActionContext > At 03:05 PM 9/28/2003, you wrote: > > > >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 > ------------------------------------------------------- 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
