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: [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]
RE: ValidatorLookupDispatchAction or VLDAction
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]
RE: ValidatorLookupDispatchAction or VLDAction
:-D Oh, okay... so we aren't going to get ahead of ourselves? Shucks! I thought the goal was to get everything done good enough and then move on ;-). Thanks for the tip. I will check out the needs in commons. Brandon Goodin -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 11:25 AM To: [EMAIL PROTECTED] Subject: RE: ValidatorLookupDispatchAction or VLDAction P.S. When will the 2.0 discussions start? I would love to be involved in them... If you're anxious to talk about 2.0 why not volunteer some time in the commons projects we're dependant on so we can finish 1.1? DBCP and Pool still need some work. David _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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]
RE: ValidatorLookupDispatchAction or VLDAction
:-D Oh, okay... so we aren't going to get ahead of ourselves? Shucks! I thought the goal was to get everything done good enough and then move on ;-). Thanks for the tip. I will check out the needs in commons. Thanks! Any help you can give is much appreciated. David _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ValidatorLookupDispatchAction or VLDAction
good ol' LookupDispatchAction I know folks are using it and seem to like it, but I created it in the context of a project gone way wrong and now that I'm on to something bigger and better I have not used it at all, believe it or not. I just want to say my apologies to the Struts team for creating such a beast. :)) No offense, Brandon - I just cringe when I think about what making Action a class rather than an interface has done to us and the hoops we jump through to deal with it. Erik On Sunday, March 30, 2003, at 01:50 PM, Brandon Goodin wrote: I have made some needed changes and updates to the ValidatorLookupDispatchAction (scheduled for 1.2). But, I cannot decide on whether I should keep the name as ValidatorLookupDispatchAction (which is a mouthful) or change it to VLDAction (tight! baby!). What do you all think? Brandon Goodin - 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]
Re: ValidatorLookupDispatchAction or VLDAction
I have made some needed changes and updates to the ValidatorLookupDispatchAction (scheduled for 1.2). But, I cannot decide on whether I should keep the name as ValidatorLookupDispatchAction (which is a mouthful) or change it to VLDAction (tight! baby!). What do you all think? -1 The longer name describes what the class does. If I wanted to use mangled abbreviations I'd be doing C. David _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ValidatorLookupDispatchAction or VLDAction
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 :-) Brandon Goodin -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 7:07 AM To: Struts Developers List Subject: Re: ValidatorLookupDispatchAction or VLDAction good ol' LookupDispatchAction I know folks are using it and seem to like it, but I created it in the context of a project gone way wrong and now that I'm on to something bigger and better I have not used it at all, believe it or not. I just want to say my apologies to the Struts team for creating such a beast. :)) No offense, Brandon - I just cringe when I think about what making Action a class rather than an interface has done to us and the hoops we jump through to deal with it. Erik On Sunday, March 30, 2003, at 01:50 PM, Brandon Goodin wrote: I have made some needed changes and updates to the ValidatorLookupDispatchAction (scheduled for 1.2). But, I cannot decide on whether I should keep the name as ValidatorLookupDispatchAction (which is a mouthful) or change it to VLDAction (tight! baby!). What do you all think? Brandon Goodin - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ValidatorLookupDispatchAction or VLDAction
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]
