A major downside of DynaBeans is that you lose all notion of compile type safety/checking. This is also one of its major strengths.
It takes a lot of discipline to not pollute your code with magic strings - which leads to a potential maintenance nightmares. I find this all the time in code inspections. The other downside of not having compile time safety is that you lose code completion in an IDE. I know that people are out there battling away without it (I used to be one of you), but once you start using it, you become hooked. ;-) That all said, I have used them very successfully on my project. Especially in combination with the validator like Ted mentions below. Regards, Oliver PS: Given more time I would investigate using something like Castor to generate my beans. that way I could get the best of both worlds. Declare my form beans in XML (XML Schema to be precise), but get compile time safety. > -----Original Message----- > From: Afshartous, Nick [mailto:[EMAIL PROTECTED]] > Sent: Monday, 25 November 2002 10:27 > To: '[EMAIL PROTECTED]' > Subject: RE: Benefits of Dynaforms > > > > 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]>
