On 6/23/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > WebWork actions are somewhat like Struts Action and ActionForm > combined: they can transfer request parameters and can be stateful, > like ActionForm, but they also can process input events, like Action. >
You'll also see this pattern implemented in most JSF-based applications, where the Java class is generically called a "backing bean" since there is no JSF-mandated requirement to implement a particular interface, or extend a particular base class. JSF's components eliminate most of the reasons you need a form bean at all in Struts, so the model properties can be of native types, rather than Strings. JSF's managed beans deal with the choice of whether you want these beans to be request or session scoped (and, as with Struts, request scope is the default recommendation). If you want a little more support for application level events, instead of just UI component events, look at Shale in conjunction with JSF :-): http://struts.apache.org/shale/ > I created several rather generic action classes, like DialogAction or > CRUDAction, and now working on WizardAction. In all cases I need to > process events in DispatchAction style, and at the same time I have > session-scoped data, which I store in ActionForm. So, sometimes Action > classes do nothing more, than just receive input command, and channel > it to actual handler in the ActionForm. > > I think that Struts should have WebWork-style action, which can do > both: keep data and process events. What is opinion on that? What is > common pattern to introduce new features in Struts? Should I just > submit the patch to Bugzilla and encourage people to vote? > I suspect this is going to be a hard sell for Struts 1.x, unless it is packaged as an *alternative* approach -- breaking backwards compatibility on how standard actions and action forms work would not be looked upon favorably. Adding a different approach (in addition) might be accepted (but at the cost of added complexity and having to explain to users why they would choose one pattern over the other). > Michael. > Craig > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
