Erik
James Mitchell wrote:
Can you create a small sample application to demonstrate how easy it is? Create a project from the struts-example to do this. I've done this a few times with other issues/concepts (jsp under web-inf, bundle from the database, etc).I'll host the download if you want, or we can get into the struts project on sf.net. Just some ideas -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?" - Seymour Cray (1925-1996), father of supercomputing-----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 11:12 AM To: Struts Developers List Subject: Re: Benefits of Dynaforms Let me just emphasize the downsides that I mentioned already... using DynaForms would mean that I would be hand-coding struts-config.xml and validation.xml. By writing a ValidatorActionForm Java class for all my forms I have to do neither now, and XDoclet is automatically generating these configuration files for me. If anyone is doing something slicker or more automated with this stuff, I'd love to hear about it, but so far I've not encountered anyone accomplishing it to this degree. Erik Afshartous, Nick wrote:Sounds like there are many benefits to using DynaForms but is there any downside ? For instance, not having explicit getters means using a generic get method that has return type Object. This in turn means having to use typecasts to cast from Object to some other type The drawbacks of typecasting are the extra run-time overhead plus the possibility of a ClassCastException. I think its a common tradeoff (flexibility versus type-safety). The Ofbiz project (www.ofbiz.org) also pushes the idea of using XML configuration files to define what kind of data is used in the application. It seems like more of an end-to-end solution though than Struts since Ofbiz facilitates automatic construction of the presentation, business, and data access layers all via XML configuration. I didn't see any mention of Ofbiz in the archives and was just wondering if there's been any discussion about this ? Nick -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:45 PM To: Struts Developers List Subject: Re: Benefits of Dynaforms 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]>-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
