Seems to be a quite clean and nice solution.
And the most important thing: I will not confuse the user!
So i vote for this implementation.
Cu,
Dave
Igor Vaynberg 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.
-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
-------------------------------------------------------
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
