SubmitButton.onSubmit just makes it easier to insert some code that runs
AFTER the form processing is done. I guess instead you would need to do
this:
New SubmitButton() {
public void onclick() {
super.onclick() <== causes form processing
== add your own logic here ==
}
}
As opposed to doing this
New SubmitButton() {
public void onSubmit() {
== add your own logic here ==
}
}
I am fine either way, the advantage of onSubmit is that the form processing
is done for you by default and that's the whole point of the separate class.
Maybe even make onclick final in SubmitButton.
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
-Igor
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Michael Jouravlev
> Sent: Thursday, August 11, 2005 4:01 PM
> To: [email protected]
> Subject: Re: [Wicket-user] Problem with CompoundPropertyModel
> and multiple Submit Buttons
>
> You lost me. I thought that getform().process() does form
> processing, and button's onclick() is a one-stop solution. I
> thought that everything is called from onclick(), like this:
> button.onclick()
> form.process()
> form.onsubmit()
>
> but looks like you prefer
>
> form.onsubmit()
> button.onclick()
> button.onsubmit()
>
> Callbacks again. I don't see how it is better that it is done
> now. I guess I am just tired ;)
>
> Michael.
>
> On 8/11/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > The onsubmit() in the submitbutton gets called after the form's
> > onsubmit() method. This way you can add some code after the
> form, like
> > redirect to a different page.
> >
> > This allows you to have lets say two buttons that update
> your model,
> > but based on which one you pressed you go to a different page.
> > Basically just like the onsubmit() works now for
> non-immediate buttons.
> > > On 8/11/05, Michael Jouravlev wrote:
> > > On 8/11/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > > If we decide to break all backwards compat, how about
> > > >
> > > > Button {
> > > > onclick() {
> > > > }
> > > > }
> > > >
> > > > And
> > > >
> > > > SubmitButton {
> > > > onclick() { getform().process(); }
> > > > onsubmit() {} <-- called by form after form processing }
> > > >
> > > > So after the form is submitted the processing goes
> directly to the
> > > > button instead of the form, the button decides whether
> or not to
> > > > invoke the default processing of the form.
> > >
> > > I like this one. It is simple, and I see what is
> happening and where
> > > it is happening. Debugging will be really simple, just set
> > > breakpoint on onclick() and step from there.
> > >
> > > What is the onsubmit() for, why it should be a callback again?
> > >
> > > 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
