On 6/8/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Second, an ActionForm is, usually, used to repopulate an HTML form on a page when an error occurs, or when a page is initially shown. Since HTML forms only deal in Strings, another recommendation you frequently hear is to only have Strings in your ActionForms. For example, if you have a textbox in your HTML form for a user to enter a date, having a real Date field in the ActionForm can lead to problems because of the conversions that have to take place back and forth (and if I remember correctly, no conversion is done when redisplaying the HTML form anyway, so you'll get the default toString() of the Date object, which is almost certainly not what you want). If you instead make it a String field, the only conversion is when you ultimately need to pass it to the business layer, in which case you have more full control over it. So, since you probably want to be dealing with real Java data types in your business classes, but an ActionForm was designed to deal with HTML forms and therefore only Strings, trying to make an ActionForm serve both purposes can lead to problems, so its easier to just avoid the situation altogether.
Plugins like FormDef help with that. FormDef allows to nest a BO/DTO inside a dynamic form bean, and to define conversion rules. FormDef also integrates with validator. On the other hand, the whole idea of Struts/Commons Validator sucks big time, because database already has all necessary validations, domains, triggers, etc. Since most apps use database anyway, input data should either be validated directly by a database or by DAO; DAO should pull metadata from database to build validation/conversion rules. Seems that Ruby on Rails is closer to this approach, while most other frameworks do the same job twice or even three times. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
