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.
-Igor
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Michael Jouravlev
> Sent: Thursday, August 11, 2005 2:28 PM
> To: [email protected]
> Subject: Re: [Wicket-user] Problem with CompoundPropertyModel
> and multiple Submit Buttons
>
> On 8/11/05, David Liebeherr <[EMAIL PROTECTED]> wrote:
> > Why don't we just make it the simple way like SWING and
> have a Button
> > that acts like a Button?
> > When i make a new button i will juust have something like
> > Button.onClick(), not Button.unSubmit() not Form.onSubmit()
> or what ever.
>
> Yeah, baby! No, baby. Don't get me wrong, but I find Swing,
> implemented with Java interfaces too verbose.
>
> * There should be listener interface defined
> * My code should implement this interface (all all methods in
> it! it is interface after all)
> * I should call addXXXListener()
> * I should create callback handler in the listener, usually
> as anonimous class
>
> Lot of work and does not look pretty in the source file,
> especially if you used Borland Delphi before.
>
> So... why not to define standard handlers like onClick(),
> which a user can implement. if handler returns true
> ("processed"), then default handler is not called. Now here
> is a problem: there is default handler for a form, and there
> may also be a default handler for a button. So if my button
> handler returns "processed" does it mean that default button
> handler should not be called, or default form handler should
> not be called, or both? I can have parent/child and peer
> relationships. Should some basic rules be defined that if
> child processed an event, all its parents should not to? Or
> something like this.
>
> This is a lot of conditions and ambiguity. This is the reason
> why I am against default "hidden" processing. Just tell me
> what is the proper lifecycle. Wrap it in the convenience
> method which I would call in 95% of cases. In my handler (any
> handler: button handler or form handler) I would call either
> convenience method, or more fine-grained methods if I want to.
>
> There is another pretty standard choice. Event is delivered
> to, say a button. Button processes it and then generates
> another event, which is posted to event queue and then sent
> to its parent/peer component.
> Welcome to MS Windows circa 1984 ;)
>
> For me it is easier to add one-two lines of code into my own
> class and to see what is happening, than to figure out who
> calls whom and when.
> Two extra lines of code save a lot of debugging time.
>
> But I am not too upset by behind-the-scenes form processing,
> (I am much more upset by non-pretty URLs), so take my
> opinions in this thread just as they are: opinions.
>
> 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
