Quoting Hubert Rabago <[EMAIL PROTECTED]>: > That's exactly what I meant to say, of course I just didn't articulate it as > well > as you did. =) Form bean details are spread all around, violating the DRY > principle. The DTO's can be used to tell Struts how to generate dynamic > action > forms that it (and the validator) can work with, without the user having to > list > down all the fields in the struts config file. Also, the conversion from > ActionForm to app-specific DTO's can mostly be automated. >
That turns out to be more intricate than it first appears, and is the reason that ActionForm existed in the first place (and, why it's part of the *view* tier, not the model, and why it was originally created as a class and not an interface, to discourage people from using it as a DTO). A very important feature of any presentation tier is to be able to reproduce whatever the user entered, even if they made a mistake (i.e. typed "1a3" instead of "123" into a field that is backed by an int). Given the practicalities of HTTP, that gives you two basic choices: * A framework that represents input fields on the server side as Strings, and then requires post-validation conversion (basically the Struts 1.x model). * A framework where the individual user interface components manage their own conversions, and are bound to back-end DTOs or model data objects expressed as native data types (JavaServer Faces, Tapestry, and several other frameworks work this way). Interstingly, using JavaServer Faces components in front of Struts ActionForms will let you work the second way if you want to, and use action forms that have native data types with no problems. You'll also find that there is not always (or even often, in my experience) a 1:1 relationship between "the sets of fields on a form" and "the set of model data objects that provide information to, or accept updates from, that form". My feeling is that you're always going to want separate abstractions; the secret for a framework is to minimize the amount of work required to deal wth that reality. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
