11/20/2002 3:09:36 AM, Erik Hatcher <[EMAIL PROTECTED]> wrote: >As for DynaActionForm's.... I still don't get their benefit. Do >you use them? Or right ActionForm subclasses? Its even less >code to "write" to do a form bean for me, because my IDE >generates all the getter/setters, and being able to generate >validation.xml makes it so worthwhile. :)
The nice thing about DynaForms is that they are a "simple" solution to a simple problem: I just want to store and validate some simple properties on the presentation layer before passing them up to the business tier. Sure some tools can make JavaBeans very easy to write. DynaBeans are just another one of those tools, and a GUI independant tool at that. It doesn't matter if you are using Eclipse or IntelliJ or JBuilder. A DynaBean is a DynaBean. And before long, I'm sure the IDEs will be helping you code DynaBeans too =:0) The truly excellent part is that you can extend DynaActionForm to create complex helper properties when you need them, or just use the base class when you don't. YMTD. But here's the kicker: With the help of the Validator and a handful of standard Actions, DynaBeans open the door to doing the ~entire~ presentation tier via XML configuration files. I rarely write custom Actions any more. With DynaBeans, I may also be able to get out of writing custom ActionForms. Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any "real" programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many "necessary evils" as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the "real programming" on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the "missing buffer" we need for data-entry. What about a DynaBean class that included a "shadow" String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
