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]
