I'm not looking to get rid of the ActionForm objects, just automate its creation based on my DTO for cases where it makes sense. Today, a lot of my forms do something like this:
1. Caller brings up the page with Form A (let's say an Edit Record form) 2. Action responds by requesting data from business tier and gets a DTO 3. Action converts DTO into ActionForm (AF) to represent all fields as strings 4. JSP shows form with values from AF 5. Form gets submitted after user edits it 6. Action receives AF and converts the data to populate a DTO 7. DTO is sent to business tier for processing What I'm thinking is automating steps 3 and 6, and automate the definition of the AF. There will still be an AF for the reasons you've given, it's just that when there's a close match between the DTO and the AF, the programmer can just let the framework take care of defining the AF (or the DynaAF, in this case) and populating it from the DTO. That way, if my DTO already has fields for name (String), age (int), and birthDate (Date), I won't have to explicitly outline a DynaActionForm with name, age, and birthDate fields and manage the conversion. The framework would be able to do it for me. Yes, some config file will still say "Convert dates using this pattern; For this specific form or field, use this pattern" but most other fields can be automated with little config requirements. There'll still be an ActionForm (or the Type 2 conceptual bean you earlier described) and it's still what gets passed to the JSP and to the validator. I just want the framework to know what fields should be on the ActionForm based on a DTO I'll supply, instead of making me type it into the struts-config or creating a new class that's basically String-based counterpart. Of course, this won't match each and every use case; I don't have a one-to-one relationship between my AFs and DTOs. I'm just looking to use something like this when I find myself creating a String-ified version of an existing DTO. thanks, Hubert --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > > 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 > __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
