In 7/11/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > I wanted to post something like "Rick, Ted and other orthodox guys, > check out this guy's suggestion", but then I decided not to ;-)
Wow! That may have been the first time anyone has ever accused me of being "orthodox" :) I've never used this strategy myself, but I don't see anything wrong with it. In fact, if I were to start coding in Java again, this is the strategy I would probably use. At this point, I'm accustom to having a code-behind, and the ActionForm is the closest thing Struts has to a code-behind. If I were to use this strategy, I'd select the parameters to the Execute signature with care. There may not be any reason to pass the HTTP parameters out of the call, and there may be a reason to pass the Action. I would just be careful of using the parameters from the Struts Execute signature, unless my code actually needed those parameters.. I also wouldn't hestitate to put some "traffic cop" code into the base Action as needed, so that the ActionForm execute can focus on what it needs to do, rather than what the application needs to do. I'd also consider using a base ActionForm with all the properties my application needs, which I could then extend with execute and validate methods, as needed. Though, I'd probably use a DynaActionForm instead of a conventional ActionForm as the base class, just for the agility. Most importantly, I'd make very sure that all my "code-behind ActionForms" were request scope, probably by changing the factory default. -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
