On 1/26/06, Ted Husted <[EMAIL PROTECTED]> wrote: > On 1/24/06, Laurie Harper <[EMAIL PROTECTED]> wrote: > > - add a Cancelable interface which an Action must implement to get > > cancel processing; ignore the cancel param if the interface isn't > > implemented > > I'd lean toward the interface approach, since that's the sort of thing > that WW2/Action2 does/will do. Duty now for the future!
I thought that change was proposed for Struts 1.x > * Add an optional "Cancellable" marker interface for Actions. > > * When cancel signal is present, a RP command checks for the interface > and throws an exception if Cancellable is not implemented. > > * For Action 1.3, add a Controller attribute "ObserveCancellable" with > the default value FALSE, that the RP command would check before > throwing an Exception. (Instead, it might just log a DEBUG-level > warning.) > > ** To enable the interface, a developer can set the Controller > attribute to TRUE. Otherwise, we break backward compatiblity, and we > would need to increment the major version number. The problem is not in the Cancel button, the problem is autopopulation. I don't see how Cancel event differs from other events and don't see the point to make a separate use case out of it. Instead, make population explicit, this works especially well with dispatch actions. In this case it would not matter cancel or not, because I can choose whether to populate form or not explicitly. One line of code in my event handler is not a big deal but it makes things much simpler. Why having a bad solution and then trying to counter-balance it with interfaces and such, if we can remove the bad solution (auto-population) altogether? Maybe we can have both: no autopopulation and cancel mapping/iterface for legacy apps. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
