On Tue, 08 Feb 2005 17:01:14 -0600, Joe Germuska wrote:
> 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" co
>> ntextClass="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 -- or easy to drop in an IOC container call.
> * 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.
I think the pluggable subclass solution is fine for now. At some point, we
might want to look to an IOC solution, but that can wait until we finish fry
the bigger fish :)
>
> 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.
>
> Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
