dynabeans: http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils /package-summary.html dynaforms: http://jakarta.apache.org/struts/api/org/apache/struts/action/package-summar y.html
> -----Original Message----- > From: Satterwhite, Frank [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 9:56 AM > To: 'Struts Developers List' > Subject: RE: Custom Actions? (was RE: Benefits of Dynaforms) > > > Can anyone point me to the apis for dynaforms (beans) > > fs > > -----Original Message----- > From: Andre Beskrowni [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 9:48 AM > To: 'Struts Developers List' > Subject: Custom Actions? (was RE: Benefits of Dynaforms) > > > ok, this one sentence in ted's post caught my eye: > > > I rarely write custom Actions any more. > > whoah. how is this possible? most of our web pages > represent some sort of > database operation: displaying, creating, updating, or > deleting. i can see > how you can minimize the amount of code that would vary in > individual Action > classes, but i don't see how could eliminate the need for subclassing > altogether. maybe i'm just completely misunderstanding here. > could you > elaborate on your process? > > thanks, > > ab > > > 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]>
