Oh man! You guys just went nuts there. I'm totally fine with how it is now, I just think the property name is a bit odd. Why do we need to refactor the whole thing?
How about this: setValidateAndBind(boolean) On 8/11/05, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > okay. i really WANT to leave this alone. people are just complaining > about it all day!! i have half a mind to just change it back to "immediate" > and call it a day... and if that satisifies everyone, this refactor > seems like a > waste. > > if you think you've really got a better idea, i'd like to propose you do > this: > > - do the complete refactor you have in mind (ready to check in) > - iron out all the details > - test the refactor and use it > - update example applications to demonstrate all major use cases > - write up short, but detailed explanation > - don't check it into head until all the devs vote on it and agree > > anything that causes at least me, chris, juergen, eelco and martijn to > agree is probably a step in the right direction... and a change this big > and this central to all wicket users really ought to be unanimous. > > as you run into limitations in your design that are tradeoffs you should > check in with the group to see if we think we can swallow whatever > it is that you want to break, change, extend or limit. in other words, > don't spend 5 days changing the whole architecture of forms and > expect everyone to let you check it in. but if it makes things simpler, > easier, less coding and more obvious AND doesn't break existing clients > AND doesn't mean they have to learn something new to do the simple > form processing they're already doing... we're all pretty logical people... > > anyway, go play. let's see full on code if you think you know how to > make this more ideal. but be sure you understand what's already in there > and write code that doesn't break existing clients. if you /must/ break > existing clients, it cannot be a change that will silently slip by. it > ought > to cause a fatal compile error. > > sound good? > > Igor Vaynberg wrote: > > >I'll do the refactor only if you promise not to tweak the form in head > >anymore. I hate refactoring my refactoring! > > > >-Igor > > > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] On Behalf Of > >>Jonathan Locke > >>Sent: Thursday, August 11, 2005 5:04 PM > >>To: [email protected] > >>Subject: Re: [Wicket-user] Problem with CompoundPropertyModel > >>and multiple Submit Buttons > >> > >> > >>sounds to me like we still don't quite know what it is. how > >>about this? > >>you guys agree on this and then go do the refactor and see > >>how it works. > >>if the experiment seems to be great, we can take a look at it > >>and vote on that. this way, we're not talking around in > >>circles like we have been for the past couple days. > >> > >>Igor Vaynberg wrote: > >> > >> > >> > >>>LOL, ok here it is as far as I can see it, and we can vote on it. > >>> > >>>Interface Ibuttonlistener { public void onButtonClicked() } > >>> > >>>Public abstract class AbstractButton extends FormComponent { > >>> (abstract?) void onClick(); > >>> ... All common stuff goes here, if there isnt any we > >>> > >>> > >>can get rid of > >> > >> > >>>this class ... > >>>} > >>> > >>>Public class Button extends AbstractButton implements > >>> > >>> > >>Ibuttonlistener { > >> > >> > >>> ... > >>> final void onButtonClicked() { > >>> onClick(); > >>> } > >>>} > >>> > >>>Public class SubmitButton extends AbstractButton implements > >>>IButtonListener { > >>> ... > >>> final void onButtonClicked() { > >>> getForm().process(); > >>> onClick(); > >>> } > >>>} > >>> > >>>Lets worry about the implementation details later, the gist is: > >>> > >>>You have a Button class which works like an immediate > >>> > >>> > >>button, and you > >> > >> > >>>have a SubmitButton class which works like a non-immediate > >>> > >>> > >>button. In > >> > >> > >>>either class you can override onClick() - in SubmitButton class this > >>>gets called AFTER the form has been processed. > >>> > >>>-Igor > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: [EMAIL PROTECTED] > >>>>[mailto:[EMAIL PROTECTED] On Behalf > >>>> > >>>> > >>Of Jonathan > >> > >> > >>>>Locke > >>>>Sent: Thursday, August 11, 2005 4:47 PM > >>>>To: [email protected] > >>>>Subject: Re: [Wicket-user] Problem with CompoundPropertyModel and > >>>>multiple Submit Buttons > >>>> > >>>> > >>>>i just can't follow this discussion any more. please let > >>>> > >>>> > >>me know when > >> > >> > >>>>everyone agrees so i can think and/or vote on the proposal. > >>>> > >>>>thanks, > >>>> > >>>> jon > >>>> > >>>>Igor Vaynberg wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Its not that I don't trust the user, the point is to > >>>>> > >>>>> > >>>>> > >>>>> > >>>>automate the 90% > >>>> > >>>> > >>>> > >>>> > >>>>>use case which is to have something happen after the default form > >>>>>processing updates your model. > >>>>> > >>>>>The internalOnClick will be finalized. So if you don't > >>>>> > >>>>> > >>want default > >> > >> > >>>>>form processing you extend from Button, and if you do want it you > >>>>>extend from SubmitButton and onclick in that class gets > >>>>> > >>>>> > >>called AFTER > >> > >> > >>>>>the form has been processed and model updated. > >>>>> > >>>>>-Igor > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: [EMAIL PROTECTED] > >>>>>>[mailto:[EMAIL PROTECTED] On Behalf > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>Of Michael > >>>> > >>>> > >>>> > >>>> > >>>>>>Jouravlev > >>>>>>Sent: Thursday, August 11, 2005 4:30 PM > >>>>>>To: [email protected] > >>>>>>Subject: Re: [Wicket-user] Problem with CompoundPropertyModel and > >>>>>>multiple Submit Buttons > >>>>>> > >>>>>>So the call chain would be: > >>>>>> > >>>>>>Button.internalOnClick() > >>>>>>form.process(); > >>>>>>onClick(); > >>>>>> > >>>>>>Where I can override onClick() for regular button, or override > >>>>>>internalOnClick() for Cancel button, right? > >>>>>> > >>>>>>I still cannot get why it cannot simply be like your > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>previous version, > >>>> > >>>> > >>>> > >>>> > >>>>>>but without onSubmit(): > >>>>>> > >>>>>>Button { > >>>>>>public void onClick() {} > >>>>>>} > >>>>>> > >>>>>>SubmitButton { > >>>>>>public void onClick() { > >>>>>> form.process(); > >>>>>> // add custom code here > >>>>>>} > >>>>>>} > >>>>>> > >>>>>>What, you do not trust a user, who might throw away > >>>>>>form.process() call? > >>>>>> > >>>>>>Michael. > >>>>>> > >>>>>>On 8/11/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>OR > >>>>>>> > >>>>>>>To make it cleaner the button can have an internal method > >>>>>>> > >>>>>>> > >>>>>>>Button { > >>>>>>> public void internalOnClick() { > >>>>>>> onClick(); > >>>>>>> } > >>>>>>> > >>>>>>> public void onClick() {} > >>>>>>>} > >>>>>>> > >>>>>>>SubmitButton { > >>>>>>> public void internalOnClick() { > >>>>>>> form.process(); > >>>>>>> onClick(); > >>>>>>> } > >>>>>>> > >>>>>>> public void onClick() {} > >>>>>>>} > >>>>>>> > >>>>>>> > >>>>>>>Yes, I think that's much better > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>------------------------------------------------------- > >>>>>>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 > ------------------------------------------------------- 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
