You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2004/10/29 18:50:19 UTC
Re: ActionErrors / ActionContext
On Fri, 29 Oct 2004 11:31:34 -0500, Joe Germuska wrote:
>�Anyone have strong feelings about the method name? �Obviously we
>�can't use "validate".
Are we going to make any API additions in 1.3.x or 1.4.x?
For example, Validate includes a parameter for the ServletRequest. Are we going to migrate that to a ActionContext (or something)?
If so, we could use ActionMessages with the new signature, and deprecate the old. If the parameters are different, then the signature is different.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionErrors / ActionContext
Posted by Craig McClanahan <cr...@gmail.com>.
On Sat, 30 Oct 2004 10:47:04 -0700, Martin Cooper <mf...@gmail.com> wrote:
> On Sat, 30 Oct 2004 08:58:56 -0500, Joe Germuska <jo...@germuska.com> wrote:
> > At 4:07 PM -0400 10/29/04, Ted Husted wrote:
> > >Perhaps it should be based on the Chain Context, which has
> > >implementations for various platforms.
> >
> > I've thought about this, but I've also had reservations about
> > separation of concerns. I haven't thought very hard about it, so
> > I'll wait until I have before I try to decide how I feel about it.
> > When you suggest that, then I wonder why we wouldn't just throw away
> > Actions all together and just have people write Commands instead.
> > One reason would just be not to change too much on people all at
> > once, which is a pretty good reason, I guess.
>
> Bingo. I've been wondering about this pretty much since Chain came
> along. Now that we have Commands, there really doesn't seem to be much
> reason for Actions other than backwards compatibility. So rather than
> have a standard Action that delegates to a chain, it seems to me that
> it would make more sense to base things on Chain, and have a standard
> Command that delegates to an Action to preserve backwards
> compatibilty.
>
+1 ... that (build the 1.3 world on chain) has been my feeling as well.
However, for people with existing apps that want to experiment with
using chains for their business logic, though, I did check in a couple
of standard actions that let you do it the other way, and invoke a
chain from an Action -- one that takes the name of the chain from the
"parameter" property on the <action> element, and one that takes it
from a request parameter. So you can gradually chain-ify your
business logic going that direction as well.
> --
> Martin Cooper
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionErrors / ActionContext
Posted by Martin Cooper <mf...@gmail.com>.
On Sat, 30 Oct 2004 08:58:56 -0500, Joe Germuska <jo...@germuska.com> wrote:
> At 4:07 PM -0400 10/29/04, Ted Husted wrote:
> >Perhaps it should be based on the Chain Context, which has
> >implementations for various platforms.
>
> I've thought about this, but I've also had reservations about
> separation of concerns. I haven't thought very hard about it, so
> I'll wait until I have before I try to decide how I feel about it.
> When you suggest that, then I wonder why we wouldn't just throw away
> Actions all together and just have people write Commands instead.
> One reason would just be not to change too much on people all at
> once, which is a pretty good reason, I guess.
Bingo. I've been wondering about this pretty much since Chain came
along. Now that we have Commands, there really doesn't seem to be much
reason for Actions other than backwards compatibility. So rather than
have a standard Action that delegates to a chain, it seems to me that
it would make more sense to base things on Chain, and have a standard
Command that delegates to an Action to preserve backwards
compatibilty.
--
Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionErrors / ActionContext
Posted by Joe Germuska <Jo...@Germuska.com>.
At 4:07 PM -0400 10/29/04, Ted Husted wrote:
> > That's a good point. Start simply by making ActionContext have
>> bean properties for the four objects normally passed into execute?
>
>Someone mentioned they were already using an ActionContext in their
>own apps. Was it you, Joe?
Yes, we use this as the basis of our most recent app, and I've been
experimenting with it for a while. We have a base dispatch-type
action which creates the ActionContext and invokes a method which
takes it as the signature.
There are risks of taking too much advantage of having a lot of
information packed into this one object -- you might pass it
everywhere and end up writing things more tangled than perhaps they
should be. But then, it also makes it easier to extract methods,
which is a refactoring of which I'm particularly fond.
We've also added a few utility methods to the ActionContext based on
the fact that it has direct access to the request: for instance, a
few variations of "addMessage" and "addError" which manage a pair of
ActionMessages objects internal to the ActionContext. Also a
"findForward" method which just avoids continually chaining
context.getMapping().findForward(). I can imagine that adding
behavior to a context clas vs. keeping it lean and just a container
for references could be a heated discussion -- but as long as there's
a factory process allowing folks to specify an alternative
ActionContext implementation, then there need be little argument.
>Perhaps it should be based on the Chain Context, which has
>implementations for various platforms.
I've thought about this, but I've also had reservations about
separation of concerns. I haven't thought very hard about it, so
I'll wait until I have before I try to decide how I feel about it.
When you suggest that, then I wonder why we wouldn't just throw away
Actions all together and just have people write Commands instead.
One reason would just be not to change too much on people all at
once, which is a pretty good reason, I guess.
>What I'd like to work towards is passing an ActionContext around the
>controller and then passing a StrutsContext out to the view.
>
>The StrutsContext would be an "API bean", like the one contemplated here.
>
>*
>http://struts.apache.org/api/org/apache/struts/config/ConfigHelperInterface.html
Yes, I like this.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionErrors / ActionContext
Posted by Ted Husted <hu...@apache.org>.
> That's a good point. Start simply by making ActionContext have
> bean properties for the four objects normally passed into execute?
Someone mentioned they were already using an ActionContext in their own apps. Was it you, Joe?
Perhaps it should be based on the Chain Context, which has implementations for various platforms.
* http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/Context.html
The request, session, application, and cookie contexts could all be contexts within the ActionContext.
If an application didn't need access to special services (and many don't), this could make it possible for people to write "POJO". But, if they needed platform services, they could cast it whatever platform they expect be using.
What I'd like to work towards is passing an ActionContext around the controller and then passing a StrutsContext out to the view.
The StrutsContext would be an "API bean", like the one contemplated here.
* http://struts.apache.org/api/org/apache/struts/config/ConfigHelperInterface.html
Views could then look to the StrutsContext for whatever they needed from us, rather than poking around in the various scopes.
Eventually, this could open the door to having multiple Struts Controllers. Each module could have their own controller filter or servlet, and we wouldn't have to support all the "special case" code.
The servlets and filters already have cannonical names in the web.xml. These could be keys into a master context. When the request passes through, the context for it's controller is added, and we proceed from there.
-Ted.
On Fri, 29 Oct 2004 12:18:32 -0500, Joe Germuska wrote:
> Well, I've mentioned before that I find an ActionContext appealing.
> That's a good point. Start simply by making ActionContext have
> bean properties for the four objects normally passed into execute?
>
> I think we'd want to have a factory process for getting instances
> of the ActionContext, because the way we use it, we put lots of
> things specific to our app design in there as well.
>
> In a Chain world, that could just be a command found using the
> "lookup" functionality, with a default lookup which just made a new
> instance.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionErrors / ActionContext
Posted by Joe Germuska <Jo...@Germuska.com>.
At 12:50 PM -0400 10/29/04, Ted Husted wrote:
>On Fri, 29 Oct 2004 11:31:34 -0500, Joe Germuska wrote:
>>ÝAnyone have strong feelings about the method name? ÝObviously we
>>Ýcan't use "validate".
>
>Are we going to make any API additions in 1.3.x or 1.4.x?
>
>For example, Validate includes a parameter for
>the ServletRequest. Are we going to migrate that
>to a ActionContext (or something)?
>
>If so, we could use ActionMessages with the new
>signature, and deprecate the old. If the
>parameters are different, then the signature is
>different.
Well, I've mentioned before that I find an
ActionContext appealing. That's a good point.
Start simply by making ActionContext have bean
properties for the four objects normally passed
into execute?
I think we'd want to have a factory process for
getting instances of the ActionContext, because
the way we use it, we put lots of things specific
to our app design in there as well.
In a Chain world, that could just be a command
found using the "lookup" functionality, with a
default lookup which just made a new instance.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love
Supreme,' I'll turn back; I'll know I'm in the
wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org