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]>
