struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mainguy, Mike" <>
Subject RE: ActionForwards, et al (was SuccessAction)
Date Tue, 12 Aug 2003 22:03:14 GMT
This conversation seems to be a by-product of looking at the Action classes
as children of the servlet and consumers of messages instead of stand-alone
One intriguing way of dealing with this (IMHO) would be to consider elements
as being able to "Pull" the required components out of some other area
(Context?) (much like how the Turbine framework does).  Instead of Chaining
commands or passing a context to every execute(), you would make available a
generic application infrastructure that you could pull your required
components from.  
Really this is probably just a semantic difference as the implementation (in
my mind) would probably be much the same, but, to me when you word it as
something 'Pulling' something out of the Context it makes more sense (errr,
I can visualize it better at least) than trying to guess what should be
'Passed' along.

-----Original Message-----
From: Ted Husted [] 
Sent: Tuesday, August 12, 2003 5:37 PM
To: Struts Developers List
Subject: Re: ActionForwards, et al (was SuccessAction)

Craig R. McClanahan wrote:
> One of the potential problems in a Context-based environment is knowing
> which keys you are using to store and retrieve stuff -- obviously, the
> producer and consumer of a piece of data need to agree.  It is also
> important that people looking at a Command should be able to determine
> what attributes will be used for what by this particular Command.
> The convention of exposing the keys that you're using seems quite helpful
> in this regard, for at least two reasons:
> * It's automatically configurable in case you want to
>   reuse the Command implementation in a different way.
> * The fact that a "fooKey" property exists is automatically
>   documentation that your Command is going to utilize
>   a particular attribute for some purpose.

And a potential problem in any Strategy-based implementation is that you 
don't know which of the parameters are actually used by a particular 
instance. For example, every Action is passed the Response, but very few 
every actually use it.

In a framework like Struts, we can be passing some type of ActionContext 
that would have JavaBean properties corresponding to the 
"greatest-denominator" signature. So, given the properties, we'd have 
the same level of documentation as we do now.

In implementing a Strategy-based or Context-based business layer 
framework, something I'm starting to look at know is the idea of 
building validation into the Command processing. So just as we can 
validate ActionForms, you might also want to validate a Context for a 
particular Command, using the Command's Catalog name (to use the Chain 
classnames) as the key.

Of course, here, I'm talking about that fabled business layer framework 
that would live below Struts but use the same architectural patterns =:0)


To unsubscribe, e-mail:
For additional commands, e-mail:

This message and its contents (to include attachments) are the property of Kmart Corporation
(Kmart) and may contain confidential and proprietary information. You are hereby notified
that any disclosure, copying, or distribution of this message, or the taking of any action
based on information contained herein is strictly prohibited. Unauthorized use of information
contained herein may subject you to civil and criminal prosecution and penalties. If you are
not the intended recipient, you should delete this message immediately.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message