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