> -----Original Message-----
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
==////==
>
>
> At 11:58 AM +0100 2/7/05, Wolfgang Gehner wrote:
> >We don't see a case for a switching contexts within the request
> >cycle to a "ViewContext".
> >
> >- Based on *last weeks* code, we created our own context named
> >"ActContext" that extends ServletWebContext, so we could add
> >convenience methods on it that keep our action code clean (like we
> >want to get the bean in scope by calling "getBean" on the context,
> >"getIDParameter" to get a request parameter named "ID" we use as
> >rowId etc etc) With tonight's svn, it could probably extend
> >ActionContext. To plug it in, we extended
> >ComposableRequestProcessor. I suspect that extending the default
> >context will be a pretty standard thing to do, so it might be a good
> >idea to allow this:
> ><controller
> >processorClass="org.apache.struts.chain.ComposableRequestProcessor"
> >contextClass="aaa.bbb.ccc.MyContext"/>
> >Switching contexts within the request cycle would make all this more
> >difficult.
> >
> >- We also created a DispatchCmd that is modeled after
> >DispatchAction, so commands that extend it can have methods like
> >"save(Context context)" when the url is /do/testCmd?method=save
> >
> >The sample app code incl. environment (Eclipse 3.1M4 etc) is there
> >at http://sourceforge.net/projects/infonoia/
> >I will see that it gets updated tomorrow based on the nightly build
> >of tonight's svn.
>
> Based on some of this discussion, I see a few likely good steps:
>
> * ComposableRequestProcessor should isolate the production of its
> Context instance into a single method, so that it's easy for a
> subclass to cause a different implementation class of Context be
> returned.
>
+1
> * This method should return ActionContext instead of just
> o.a.c.chain.Context, so that Struts can "guarantee" that the command
> which is executed as the "root" of the chain will have one of these,
> instead of using the wrapping mechanism which is currently used only
> for the "process-view" subchain.
>
+1
> * perhaps there should be a way to simply specify an alternate
> Context class, instead of requiring a subclass of
> ComposableRequestProcessor. However, as I have things set up now, I
> don't think that's so straightforward. Context itself has no API
> about what is to be done with an initial HttpServletRequest or
> HttpServletResponse; therefore, if one were to specify a Context
> class, it would really have to be a ServletWebContext or a
> ServletActionContext. This isn't something I'm against, but I don't
> know if it's clear which they should do; until it is, it's not that
> hard to subclass ComposableRequestProcessor; this saves us the
> trouble of defining a "ContextFactory" interface which would deal
> with the setup.
>
Why open this up with setter / getter property so that IoC container
inside a subclass of the ``ComposableRequestProcessor'' can assemble
it for you?
> In short, this is where I am right now, and what I'll probably commit
> after waiting a short while for comments. With this, I would remove
> the context wrapping from the default chain, and perhaps I'd just get
> rid of those classes. (I have a hunch they might sometimes be
> useful, though, so I might just put them in commons-chain.)
> ---------------------
> public void process(HttpServletRequest request,
> HttpServletResponse response)
> throws IOException, ServletException {
>
> // Wrap the request in the case of a multipart request
> request = processMultipart(request);
>
> // Create and populate a Context for this request
> ActionContext context = contextInstance(request, response);
>
> // Create and execute the command.
> try {
> if (log.isDebugEnabled()) {
> log.debug("Using processing chain for this request");
> }
> command.execute(context);
> } catch (Exception e) {
> // Execute the exception processing chain??
> throw new ServletException(e);
> }
>
> // Release the context.
> context.release();
> }
>
> protected ActionContext
> contextInstance(HttpServletRequest request,
>
> HttpServletResponse response) {
> // Create and populate a Context for this request
> ServletWebContext context = new ServletWebContext();
> context.initialize(getServletContext(), request, response);
> context.put(Constants.ACTION_SERVLET_KEY,
> this.servlet);
> context.put(Constants.MODULE_CONFIG_KEY,
> this.moduleConfig);
> return new ServletActionContext(context);;
> }
> ---------------------
>
> Any feedback is appreciated.
>
--
Peter Pilgrim
Operations/IT - Credit Suisse First Boston,
10 South Colonnade, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497
==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
