Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
Message-ID: <3F39DF59.2030303@xenonsoft.demon.co.uk>
Date: Wed, 13 Aug 2003 07:48:57 +0100
From: "Peter A. Pilgrim" <peterp@xenonsoft.demon.co.uk>
Organization: XeNoNSoFT 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030718
MIME-Version: 1.0
To: Struts Developers List <struts-dev@jakarta.apache.org>
Subject: Re: ActionForwards, et al (was SuccessAction)
References: <20030812182851.22886.qmail@web20703.mail.yahoo.com>
 <3F3942AE.3080301@xenonsoft.demon.co.uk> <3F3946D4.7020800@apache.org>
 <3F3968D5.8020307@xenonsoft.demon.co.uk>
 <20030812172649.J29386@minotaur.apache.org>
In-Reply-To: <20030812172649.J29386@minotaur.apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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 ''


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org