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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Ted Husted, Struts in Action <http://husted.com/struts/book.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
