Are we talking about making these changes in the form?!? I thought this started out talking about buttons not forms. I might want to have two buttons that bypass form processing and do two different things. Right now its easy to do, just create two buttons and set their setDefaultFormProcessing(false) and voila. If I want to have two buttons that actually update my model side by side with the two that don't, that's easy too.
I think this is a per-button case problem and has nothing to do with the forms! -Igor > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jonathan Locke > Sent: Thursday, August 11, 2005 1:59 PM > To: [email protected] > Subject: Re: [Wicket-user] Problem with CompoundPropertyModel > and multiple Submit Buttons > > > yeah, final would do the trick all right. i could be +1 on > this breakage if it makes everyone including michael > completely happy. onValidSubmit() is a much more > self-explanatory name. > i'm still mentally searching for the best and most > self-evident names here... what about > onHandleSubmit() instead of onCustomSubmit()? then you override > onValidSubmit() if > you just want to deal with valid submits and if you want more > control you override onHandleSubmit() to take over the form > processing yourself... ?? > > Martijn Dashorst wrote: > > > Jonathan Locke wrote: > > > >> although fixing this is nice idea, keep in mind that we're > going to > >> break the whole freaking world and people who have never > even joined > >> this list will be on hear shouting about a breaking change to > >> something as important as Form.onSubmit. i think it might > be better > >> to quietly slip in onValidSubmit() with a comment about > how it works > >> and then have a flag that basically says "yeah, i know > this is going > >> to change the way forms work"... if you set this flag, then forms > >> work the way michael suggests. > > > > > > Luckily, we don't have a manual to speak of, and I can alter the > > reference manual to show the one and only way. But I don't want to > > take this lightly. > > > > We could also be very vocal on all our forums concerning > the breaking > > of the contract. And of course, have a vote, whether our > users like it > > or not. I'm +1 for more clarity, and non-silent breaking code. So > > making onSubmit final and deprecated sounds like a very > strong signal > > ;-) > > > > Martijn > > > >> > >> Martijn Dashorst wrote: > >> > >>> BTW, > >>> > >>> I don't mean that we shouldn't cater for the advanced > user. But we > >>> should keep in mind that both types of user need special care. I > >>> would hate it when Wicket joins the legions of too complicated > >>> frameworks. > >>> > >>> I think the proposals made by Jonathan are pretty solid, > and I might > >>> even be +1 on renaming onSubmit() to onValidSubmit(), and > introduce > >>> onCustomSubmit(), removing onSumit() in order to avoid confusion. > >>> > >>> Martijn > >>> > >>> Martijn Dashorst wrote: > >>> > >>>> Michael Jouravlev wrote: > >>>> > >>>>> Same happens in Wicket, and a lot. Why do you want to do > >>>>> everything automatically? I want to have an option: to do it > >>>>> either myself or to delegate it to the framework. > >>>>> > >>>> I like having a framework doing lots of things automatically. I > >>>> don't want to have to call process(). That is completely > backwards. > >>>> In Struts/etc. I have to perform all those tasks myself, or > >>>> introduce yet another layer (interceptors, etc). This automatic > >>>> handling is what makes Wicket so easy and user friendly. > >>>> > >>>> Now, if I want to override stuff, then it should be > possible, and > >>>> the framework should not be in the way (too much). And > now we are > >>>> discussing how we can provide the advanced user with the > simplest > >>>> means of overriding the default behaviour. > >>>> > >>>> This discussion has been going on too long, so you all > are focused > >>>> on how to do the special, advanced case when you want to > override > >>>> the default handling. 90% of the time I don't want to > bypass Wicket > >>>> form processing. That 90% should be dead simple, taking no extra > >>>> coding. > >>>> > >>>> If you need more control, and can't find it in Wicket, then > >>>> probably Wicket isn't the framework that will make you happy. > >>>> > >>>> My 2 cents. > >>>> > >>>> Naming: > >>>> - setImmediate() is not quite clear IMO, but I also don' > thave too > >>>> much experience in other frameworks +0 > >>>> - setCustomizedFormProcessing()? > >>>> > >>>> Martijn > >>>> > >>>> Michael Jouravlev wrote: > >>>> > >>>>> Well, how Wicket is going to be better than Struts or > JSF if you > >>>>> are doing the same thing? A lot of built-in call sequences that > >>>>> are hard to override. Same as with Struts > reset/populate/validate. > >>>>> Everyone can turn off validation by setting parameter > in xml file, > >>>>> but it is impossible to turn reset or population off. > >>>>> > >>>>> Same happens in Wicket, and a lot. Why do you want to do > >>>>> everything automatically? I want to have an option: to do it > >>>>> either myself or to delegate it to the framework. > Consider above fragment: > >>>>> > >>>>> // when processing was triggered by a Wicket button and // that > >>>>> button indicates it wants to be called immediately // (without > >>>>> validating), call onSubmit right away. > >>>>> if (submittingButton != null && > (submittingButton.isImmediate())) > >>>>> { submittingButton.onSubmit(); } else { // validation, error > >>>>> handling, model updating, // delegating submit (to button and > >>>>> form) ... > >>>>> } > >>>>> > >>>>> Throw out this "immediate" flag and just leave it like this: > >>>>> > >>>>> // when processing was triggered by a Wicket button and // that > >>>>> button indicates it wants to be called immediately // (without > >>>>> validating), call onSubmit right away. > >>>>> if (submittingButton != null) > >>>>> { > >>>>> submittingButton.onSubmit(); > >>>>> } > >>>>> else > >>>>> { > >>>>> // validation, error handling, model updating, // delegating > >>>>> submit (to button and form) ... > >>>>> } > >>>>> > >>>>> Then allow me to call default process() method from my > onSubmit() > >>>>> method, or to call finer-grained validate(), update(), etc. > >>>>> instead of > >>>>> process(). This is it. If I want default event handling > (which I > >>>>> usually will want to), I will call process(). It is so much > >>>>> simpler to write one line of code and to see what is actually > >>>>> happening, than to figure out who and when will can > your handler. > >>>>> > >>>>> Michael. > >>>>> > >>>>> > >>>>> ------------------------------------------------------- > >>>>> SF.Net email is Sponsored by the Better Software > Conference & EXPO > >>>>> September 19-22, 2005 * San Francisco, CA * Development > Lifecycle > >>>>> Practices Agile & Plan-Driven Development * Managing Projects & > >>>>> Teams * Testing & QA Security * Process Improvement & > Measurement > >>>>> * http://www.sqe.com/bsce5sf > >>>>> _______________________________________________ > >>>>> Wicket-user mailing list > >>>>> [email protected] > >>>>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> ------------------------------------------------------- > >>>> SF.Net email is Sponsored by the Better Software > Conference & EXPO > >>>> September 19-22, 2005 * San Francisco, CA * Development > Lifecycle > >>>> Practices Agile & Plan-Driven Development * Managing Projects & > >>>> Teams * Testing & QA Security * Process Improvement & > Measurement * > >>>> http://www.sqe.com/bsce5sf > >>>> _______________________________________________ > >>>> Wicket-user mailing list > >>>> [email protected] > >>>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> ------------------------------------------------------- > >>> SF.Net email is Sponsored by the Better Software > Conference & EXPO > >>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >>> Practices Agile & Plan-Driven Development * Managing Projects & > >>> Teams * Testing & QA Security * Process Improvement & > Measurement * > >>> http://www.sqe.com/bsce5sf > >>> _______________________________________________ > >>> Wicket-user mailing list > >>> [email protected] > >>> https://lists.sourceforge.net/lists/listinfo/wicket-user > >>> > >> > >> > >> ------------------------------------------------------- > >> SF.Net email is Sponsored by the Better Software Conference & EXPO > >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle > >> Practices Agile & Plan-Driven Development * Managing > Projects & Teams > >> * Testing & QA Security * Process Improvement & Measurement * > >> http://www.sqe.com/bsce5sf > >> _______________________________________________ > >> Wicket-user mailing list > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > Practices Agile & Plan-Driven Development * Managing > Projects & Teams > > * Testing & QA Security * Process Improvement & Measurement * > > http://www.sqe.com/bsce5sf > > _______________________________________________ > > Wicket-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & > EXPO September 19-22, 2005 * San Francisco, CA * Development > Lifecycle Practices Agile & Plan-Driven Development * > Managing Projects & Teams * Testing & QA Security * Process > Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
