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]