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