> -----Original Message----- > From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED]
--//-- > > 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? > > > > >>>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 ) > > -- > Peter Pilgrim > __ _____ _____ _____ > / //__ // ___// ___/ + Serverside Java > / /___/ // /__ / /__ + Struts > / // ___// ___// ___/ + Expresso Committer > __/ // /__ / /__ / /__ + Independent Contractor > /___//____//____//____/ + Intrinsic Motivation > On Line Resume > || > \\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' > In the excitment I got caught up the discussion about customised action forward, whereas the original design intention got chucked to the side, namely a ``composable request processor''. So let me spend some time discussing this: Now I am at work. I said `RequestProcessor' currently could be rewritten as a `Chain', because it aggregates a many `Command's. But I am wondering about that statement. It would be seem to me `RequestProcessor' is a very complex `Command' Going back to the original "Decomposable request Processor" thread there were at least two concerns: 1) How delegate or nest processors so that they do the right thing. 2) Deciding which methods of the current processor should be decomposed. 3) Configuring the chain of processor from XML. Delegation: I believe would be like Servlet Filters as they are implemented now. If we have servlet filters A and B , then we know that if filter A chained to filter B. The final effect is not necessarily equal to B followed A. Methods: In the current request processor there is one method `process()' which has a default implementation: public void process(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException This method calls other ``process*'' methods. processLocale(request, response); ... processPreprocess(request, response); ActionMapping mapping = processMapping(request, response, path); ... ActionForm form = processActionForm(request, response, mapping); processPopulate(request, response, form, mapping); ... Action action = processActionCreate(request, response, mapping); ... ActionForward forward = processActionPerform(request, response, action, form, mapping); My question is if we make `RequestProcessor' a common-chain `Command' then do then in turn make it call other `Command' in order to emulate all the `process*()' calls. For example // RequestProcessor implemented as complex `Command' // Assuming we get a web context from somewhere, StrutWebContext sc = ... ; processPreprocessCommand.execute( sc ); ... ActionForm form = (Action) processActionCreate.getAttributes().get("ActionForm"); ... processActionCreate.execute( sc ); Action action = (Action) processActionCreate.getAttributes().get("Action"); ... processActionCreate.execute( sc ); ActionForward forward = (Action) processActionCreate.getAttributes().get("ActionForward"); Is this anything like what you had in mind, Craig? Because it looks to me a bit untidy, but the request processor has effectively been decomposed into commands. The problem for me is building the new request processor, complex command. what would the API look like? DefaultComplexProcessor dcp = ... ; // Our new request processor Suppose I want to intercept the process of creating a new ``Action'' instance. If we write accessor method to expose the ``Chain'' that is responsibe for creating an action, such as this: Chain oneChain =dcp.getProcessActionCreateChain(); then I could add my custom interceptor oneChain.addCommand( new ExpressoProcessActionCreateCommand() ); Is this speculation or truth? Am I on the right track or do you have something else in mind. Thoughts -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *********************************************************************************** This e-mail is intended only for the addressee named above. As this e-mail may contain confidential or privileged information, if you are not the named addressee, you are not authorised to retain, read, copy or disseminate this message or any part of it. The Royal Bank of Scotland plc is registered in Scotland No 90312 Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB Regulated by the Financial Services Authority Visit our website at http://www.rbs.co.uk/CBFM/ *********************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
