struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: ActionForwards, et al (was SuccessAction)
Date Tue, 12 Aug 2003 22:13:09 GMT
On Tue, 12 Aug 2003, Mainguy, Mike wrote:

> Date: Tue, 12 Aug 2003 18:03:14 -0400
> From: "Mainguy, Mike" <>
> Reply-To: Struts Developers List <>
> To: 'Struts Developers List' <>
> Subject: RE: ActionForwards, et al (was SuccessAction)
> 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
> entities.
> 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.
> Comments?

Doesn't "pulling" something from some application infrastructure imply
that somebody else "pushed" it into that infrastructure?  For example, if
you expect to find the HttpServletRequest object in there, presumably the
controller must have seeded that content.  It's also perfectly reasonable
for one Command in a Chain (in commons-sandbox/chain terms) to push
something into the Context that another Command executed later will need.

In terms of making the infrastructure available to callers, it's pretty
clear how passing a context object around makes the infrastructure
available to anyone who needs it.  Are there other options for how you'd
make the infrastructure available without passing it?  I haven't thought
of any.


> -----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)
> -Ted.
> ---------------------------------------------------------------------
> 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:

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

View raw message