This was just my perception from reading Struts in Action and it was also explicitly stated in a couple of "Struts Best Practices" articles I found on the web.

Personally, I found it a little bit disconcerting that Action classes, that I thought were supposed to be an implentation of the Command Design Pattern, were now being used to process multiple operations. The only rationale I have seen given for using DispatchAction and similar is that they reduce class clutter, which I feel is a fairly weak argument for distorting the original design.

However, I can see the appeal of mapping each JSP page to one Action which deals with all possible operations for that page. This means you then have a one-to-one mapping of ActionForm classes to Action classes. This in turn means you could make some simplifications to the framework (reducing its complexity and the relatively steep learning curve) and could reduce duplication when configuring applications.

Lawrie

From: "Frank W. Zammetti" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
To: "Struts Users Mailing List" <user@struts.apache.org>
CC: user@struts.apache.org
Subject: Re: Wouldn't validation be better performed by Actions rather than ActionForms?
Date: Fri, 18 Mar 2005 12:25:00 -0500 (EST)


Is it really true that DispatchAction is now the accepted "best practice"?
 If so I have to say I disagree with that standard (if not, ignore me!)

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Fri, March 18, 2005 12:17 pm, Lawrie Gallardo said:
> I'm still relatively new to Struts, but I can't help but feel that
> validation would be better performed by Action classes rather than
> ActionForm classes.
>
> It seems to me that, ideally, you want
> 1. Validation,
> 2. Transformations (ie convert separate day, month and year HTML fields to
> Java Date object), and
> 3. Mapping of ActionForm fields (/HTML parameters) to Domain POJOs / DTOs
> to all be configured in the same config file (to minimise duplication) and
> to be implemented in the same class rather than scattered between multiple
> config files and classes.
>
> Now, if my understanding is correct:
> 1. There is always a one-to-one mapping between an ActionForm and an
> ActionMapping,
> 2. Struts best practice is to have each Action class handle all possible
> operations for the HTML request it deals with using DispatchLookupAction
> or
> something similar,
> 3. Almost noone creates ActionForms manually any more - they use
> DynaActionForm (or validating variations of this). And for those who do
> still create ActionForms manually, they don't offer anything in the way of
> reuse, and are basically throw-away classes.
>
> Now if this is the case, would it not be better to have the ActionForm as
> basically a dum data holder and have the validation method in the Action
> classes instead? The strus-config.xml file could contain all the required
> declarative validation, transformation and mapping info, and the Action
> class could contain any validation, transformation, and mapping operations
> that were too complicated to be set up declaratively.
>
> Is it just down to design decisions made in early versions of Struts and
> backward compatibility that things are the way they are? Or are there good
> arguments for having the validation method in ActionForm? Am I missing
> something here?
>
> _________________________________________________________________
> Stay in touch with absent friends - get MSN Messenger
> http://www.msn.co.uk/messenger
>
>
> ---------------------------------------------------------------------
> 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]


_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to