On Thu, 10 Feb 2005 21:45:04 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > OK: the ComposableRequestProcessor now makes sure that the context > passed to the initial chain command is an instance of ActionContext > -- this feels like a much stronger model than the wrapping process. > I will probably completely remove the WrappingLookupCommand and > ContextWrapper classes from SVN. If anyone interested in chain > thinks its worthwhile, maybe I'll move them to commons-chain; > otherwise, I'll let them sit until it seems more relevant. > > There's still a historic link to ServletWebContext in the > ServletActionContext, but it seems gratuitous now that the > ServletActionContext isn't primarily used as a wrapper; I will > probably take that out soon. > > I believe now that we have a decent grounding to begin using the > ActionContext as the request-scoped parameter throughout Struts - I > think it can be applied to ActionForm and Action to hide dependencies > on the Servlet API (and in ActionForm, to finally deprecate > ActionErrors!) >
I'm not sure it is totally relevant here, but I've seen the concept mentioned peripherally ... if the intent is that Struts 1.3 should play nice in a portlet environment, the corresponding processing chain(s) should recognize the difference between the one-and-only portlet that processes the incoming submit, versus that fact that all of the portlets on the page will get asked to re-render themselves. (In Portlet API terms, this is the difference between an "action" request and a "render" request.) You'll likely want to support two separate chains, possibly with a different context object, to cover these two cases. (In Shale, benefiting from its JSF basis, the management of ViewController takes care of this difference for you; preprocess() wll be called only on the portlet that is processing the current request; however, prerender() will be called on *all* the portlets on the current page so that they can prepare whatever data is needed for that portlet to rerender itself.) > Are there any reasons not to press ahead with changes like that? > > Beyond looking at further uses for ActionContext, I also want to > start thinking about a Struts API bean which might do for the > application what ActionContext does for the request. > (Ah, that's one of the best things about Shale ... no such thing as a configuration bean, since the managed beans facility of JSF does all the work :-) > Joe Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
