On Wed, 13 Aug 2003, Peter A. Pilgrim wrote:

> Date: Wed, 13 Aug 2003 07:48:57 +0100
> From: Peter A. Pilgrim <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: ActionForwards, et al (was SuccessAction)
>
> Craig R. McClanahan wrote:
> > On Tue, 12 Aug 2003, Peter A. Pilgrim wrote:
> >
> >
> >>So we could have convenience methods such as
> >>
> >>StrutsWebContext  scontext = (StrutsWebContext)context;
> >>// Where ``StrutsWebContext'' is a type of ``ServletWebContext''
> >>
> >>ActionForm form = scontext.getActionForm();
> >>ActionMapping mapping = scontext.getActionMapping();
> >
> >
> > If we're talking about a Struts2 world (where we're willing to reconsider
> > the calling sequence of an Action anyway), wouldn't it be better to make
> > StrutsWebContext just extend WebContext instead of ServletWebContext?
> > That way we could have transparent support for servlets and portlets.
> >
> So instead you would make convenience method from WebContext instead
> I see the `WebContext.getRequestScope()' returns a mutable map of
> attribute values. In other words they are derived from
> `ServletRequest.getAttributeNames()'.
>
> But looking at the current Struts 1.1 library would you for compatibility
> reason also supply the `HttpServletRequest' object to Struts users?
>
> HttpServletRequest  = StrutsWebContext.getRequest(); // convenience method
>
> and like wise `HttpServletResponse' object?
>

In the contrib/struts-chain sources, I actually do that because I was
trying to avoid requiring any changes to the Action signature, so it is
certainly feasible.

You'll also note that I didn't try to create a StrutsWebContext at all --
just used WebContext with conventions on what attribute keys the standard
Struts objects were passed under.

> >
> >>>Another import idea is that, if we wanted, we could also add other other
> >>>convenience methods to the context without breaking the signature.
> >>>
> >>
> My question above.
>
> >>And presumably we [as application developer] will be able to subclass
> >>the ServletWebContext and add application features like Single Sign-On
> >>/ Security / personalisation etcetera. We will be able to configure
> >>Struts Module to use our custom `Context' instead of the Struts
> >>default context.
> >>
> >>Yep this is looking sexy.
> >>
> >>
> >
> >
> > Yep ... lots of interesting room for playing around here.  To say nothing
> > of the fact that you can compose your own request processor pipeline to
> > boot.
> >
>
> Moving swiftly back to the original design reason. The [old] request processor
> is now effectively a `Chain' isn't it?
>
> ( ... I will now continue this note at work )
>
>

That's what I was trying to do in contrib/struts-chain.  It doesn't
contain all the standard functionality, and hasn't been tested at all, but
it looks like the idea is feasible.

Craig


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to