No objections (wouldn't dream of it the first day on the job :)) but typically in our projects the cancelbutton is a pagelink to another page, it never touches the form. Although i can see usecases where you would want to be notified of a cancel i am not convinced it must be through a formbutton. you might as well use a link to be notified of that.
Maurice On Sun, Mar 16, 2008 at 8:51 PM, Matej Knopp <[EMAIL PROTECTED]> wrote: > Even though this is another class and api bloat and everything I don't > object actually. I had some hard time explaining people why should > they call setDefaultFormProcessing(false) and what does it do so I > think cancelbutton would be convenient to have. > > However, maybe others object more against additional two classes > (yeah, we do have plenty of classes already :)). > > -Matej > > > > On Sun, Mar 16, 2008 at 8:44 PM, Jonathan Locke > <[EMAIL PROTECTED]> wrote: > > > > i just got bit for at least the 3rd or 4th time by > > setDefaultFormProcessing(). implementing a cancel button requires that > you > > set this to false. this is a hard thing to know for a beginning user. or > > for me for that matter. ;-) i was wondering what everyone thought about > > adding AjaxCancelButton and CancelButton such that they > > setDefaultFormProcessing(false). this would be a discoverable and > > self-documenting way of dealing with this issue. true, it is > > yet-another-class-in-core (or extensions would be fine), but i think it > > might be nice. > > -- > > View this message in context: > http://www.nabble.com/cancel-buttons-tp16083133p16083133.html > > Sent from the Wicket - Dev mailing list archive at Nabble.com. > > > > > > > > -- > Resizable and reorderable grid components. > http://www.inmethod.com >
