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
