The idea behind a Struts Action is that it suppose to give you a place to call your business logic components. Rather than call various business processes through a subclass, I continue the decorator pattern by declaring the process to call as part of the ActionMapping.
I then use a standard Action which automatically populates the designed business bean and invokes the business process. The business process returns a specialized result object that the standard Action analyzes. The result object has properties that can return messsages, data, and/or new routing instructions to the Action. Basically, I'm putting my business tier behind a facade, and using the ActionMapping decorator to tell the standard Action which operation to invoke. The facade provides a consistent interface and minimizes what the Struts tier needs to know about each operation. -Ted. 11/22/2002 9:47:43 AM, Andre Beskrowni <[EMAIL PROTECTED]> wrote: >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:struts-dev- [EMAIL PROTECTED]> > >-- >To unsubscribe, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
