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