On 6 mai, 15:16, Ed <[email protected]> wrote:
> > You're breaking the principle of least surprise: if I register a
> > handler on a widget, I expect the source of the event to be that
>
> Exactly my point why I want to change the source.
> Your suggestion works with single widget components, but not really
> wel for composite widgets.
>
> Example: suppose you have a composite widget that contains a chexkbox
> and label.
> The composite contains a addClickHandler method to add a click
> handler.
> This method will simple forward the call to the underlying checkbox
> and label.
> The listener will expect the source to be the composite widget like
> you mentioned above, which isn't the case in the above (in the past
> you could change the sender widget in the listener).
In GWT 1.5, you'd have probably used a
DelegatingClickListenerCollection, which isn't different from adding a
handler to the inner widget and calling your composite's fireEvent/
delegateEvent from there (effectively changing the event's source to
be your composite).
But I think that in this case, you could just use the fact that the
click event bubbles:
http://code.google.com/webtoolkit/doc/1.6/FAQ_UI.html#How_can_I_efficiently_handle_events_from_many_interior_Widgets?
Calling addDomHandler on your composite should thus be enough.
Of course, as you said, this is a simple example...
...but I'm yet to see a concrete example of your needs that lead you
to develop this heavy/distorted "workaround" framework you're talking
about...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
