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 2003/04/04 14:14:11 UTC
Re: ValidatorLookupDispatchAction or VLDAction
The alternative Erik is thinking of is FindForward
http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/FindForwardAction.java
The idea is that you include a "forward=whatever" in the request, and it
trundles through the local and global forwards looking for "whatever".
So, rather than select a dispatch method, you can select a forward.
Personally, I'd say rather than worry about whether Action is an
Interface, that the controller should be able to support more than one
type of action class. Ideally, we should be able to extend it to support
*any* type of action. But, that's the stuff of 2.x.
Meanwhile, if I wanted to have a base action that could also be or not
be a dispatch action, I would probably just rip-off the dispatch
mechanism from the original. (Ah, the miracle of open source.) There
would be duplicated code between the original and mine, but my
application wouldn't be using the original.
If that was still unacceptable, I wager that the dispatch mechanism in
DispatchAction could be refactored into a utility class than other
Actions could call. Or, it's even possible that the utility code could
be moved up into the base Action, so any subclass could use it.
-Ted
Erik Hatcher wrote:
> On Monday, March 31, 2003, at 10:01 AM, Brandon Goodin wrote:
>
>> I'm curious why you consider it such a problem. It has solved several
>> issues
>> for me. Quite the opposite. I rarely use the base Action class :-)
>
>
> LookupDispatchAction itself requires a tighter coupling between what is
> in the presentation (the button labels) than achieving something like
> that should. I like Ted Husted's approach in his book better (I don't
> recall the class name he developed off the top of my head though).
>
> I never extend Action directly either. I like to have a thin layer
> between actions and Action... with an intermediate BaseAction, which
> extends Action. But now what happens when you want to use
> LookupDispatchAction? You can't, cleanly. So then we'd end up with a
> BaseLookupDispatchAction to maintain that thin layer, and there would be
> duplicated code.
>
> I suspect there is some way to use aggregation to embed a
> LookupDispatchAction instance inside a BaseLookupDispatchAction, but my
> current project does not have forms that have multiple submit buttons,
> so its not an issue currently.
>
> In other words, inheritance "sucks".... :) thats a bit of harsh and
> untrue statement, I know, but the point is that its the strongest OO
> coupling out there, and loosely coupled is the ideal goal, not strongly
> coupled. Action should be an interface!
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: ValidatorLookupDispatchAction or VLDAction
Posted by Brandon Goodin <ma...@phase.ws>.
The ValidatorLookupDispatchAction is it's own class. I DID duplicate the
code and made some changes that I felt needed to exist in the current
LoookupDispatchAction. For example, if the parameter is not in the the
request then it will default to the uspecified method. For example, assuming
"submit" is the parameter, '/my/foo/action.do' and
'/my/foo/action.do?submit=' will both resolve to the unspecified method.
Anyways, you can check out the code. I do like the idea of Utilitizing the
lookup process or including it in the base action. That would be ideal to
me. Utilitizing the Validator lookup would be good too. The same process
that is used in the form is the same process that is used in the
ValidatorLookupDispatchAction. Anyways, that's my .02. For now you can get
the code to the VLD at the link that is supplied on the enhancement
submission.
Brandon Goodin
P.S. When will the 2.0 discussions start? I would love to be involved in
them...
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Friday, April 04, 2003 5:14 AM
To: Struts Developers List
Subject: Re: ValidatorLookupDispatchAction or VLDAction
The alternative Erik is thinking of is FindForward
http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/java/org/a
pache/struts/scaffold/FindForwardAction.java
The idea is that you include a "forward=whatever" in the request, and it
trundles through the local and global forwards looking for "whatever".
So, rather than select a dispatch method, you can select a forward.
Personally, I'd say rather than worry about whether Action is an
Interface, that the controller should be able to support more than one
type of action class. Ideally, we should be able to extend it to support
*any* type of action. But, that's the stuff of 2.x.
Meanwhile, if I wanted to have a base action that could also be or not
be a dispatch action, I would probably just rip-off the dispatch
mechanism from the original. (Ah, the miracle of open source.) There
would be duplicated code between the original and mine, but my
application wouldn't be using the original.
If that was still unacceptable, I wager that the dispatch mechanism in
DispatchAction could be refactored into a utility class than other
Actions could call. Or, it's even possible that the utility code could
be moved up into the base Action, so any subclass could use it.
-Ted
Erik Hatcher wrote:
> On Monday, March 31, 2003, at 10:01 AM, Brandon Goodin wrote:
>
>> I'm curious why you consider it such a problem. It has solved several
>> issues
>> for me. Quite the opposite. I rarely use the base Action class :-)
>
>
> LookupDispatchAction itself requires a tighter coupling between what is
> in the presentation (the button labels) than achieving something like
> that should. I like Ted Husted's approach in his book better (I don't
> recall the class name he developed off the top of my head though).
>
> I never extend Action directly either. I like to have a thin layer
> between actions and Action... with an intermediate BaseAction, which
> extends Action. But now what happens when you want to use
> LookupDispatchAction? You can't, cleanly. So then we'd end up with a
> BaseLookupDispatchAction to maintain that thin layer, and there would be
> duplicated code.
>
> I suspect there is some way to use aggregation to embed a
> LookupDispatchAction instance inside a BaseLookupDispatchAction, but my
> current project does not have forms that have multiple submit buttons,
> so its not an issue currently.
>
> In other words, inheritance "sucks".... :) thats a bit of harsh and
> untrue statement, I know, but the point is that its the strongest OO
> coupling out there, and loosely coupled is the ideal goal, not strongly
> coupled. Action should be an interface!
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org