struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <hus...@apache.org>
Subject Re: ActionContext chain changes committed
Date Fri, 11 Feb 2005 12:27:19 GMT
Inline.

On Thu, 10 Feb 2005 20:11:59 -0800, Craig McClanahan wrote:
> On Thu, 10 Feb 2005 21:45:04 -0600, Joe Germuska <Joe@germuska.com>
> 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.

Personally, I think the intent of Struts 1.x, or any Struts release, should be to help us
write the applications we ourselves need to write. If some of us are writing portlet applications,
then, yes, this would be an excellent time to chime in as to whether this sort of thing is
needed. 

I'm told that the Struts Bridge already makes Struts applications available as a portlet,
so there might not be much to do. 

* http://portals.apache.org/jetspeed-2/multiproject/portals-bridges-struts/index.html

But, I would advise against implementing direct support for portlets unless-and-until we have
someone in the field, actively developing portlets, who can help us scratch that itch. Better
to get it right later than get it wrong now :)


> (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 :-)

Good point. IMHO, we should think about plugging in to Spring or Hivemind sooner than later.
Ideally, we should think about putting the IOC container behind a pluggable facade, so we
can have our choice of IOC container. I'm using Spring.NET with the C# implementation of Chain,
and it works great!


>
>> Joe
>>
> Craig
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message