I'm not sure if the event preview mechanism would completely solve all
the problems, but it appears to offer essentially an "override"
capability to fireEvent. If you recall our earlier discussions, the
use case goes something like this:
1) a virtual widget system exists which implements widgets which are
not actually backed by any real DOM elements, but rather drawn into a
Canvas, similar to lightweight components in Swing. (GWT Widget is
more like an AWT model, with the DOM being the 'peer')
2) we wish to introduce an event system for these widgets, complete
with an event propagation model based on component events having the
capability of propagating to a parent container
3) Our original discussion was to have the source implement an
interface like PropagationModel. A subclass of HandlerManager which
check if source instanceof PropagationModel, and if so, use the
interface to a) check if the event is a type that should be propagated
b) check if it hasn't had stopPropagation() called and c) grab the
parent widget and refire the event.
What I'm not sure of, is if I shoe-horn all this functionality into
the preview mechanism, if it will still play nice with all the
fireDepth/queuing stuff that was recently added.
-Ray
On Tue, Nov 11, 2008 at 10:37 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> The fireEvent method is currently final because our
> addHandler/removeHandler is relying on our version of fireEvents being
> called because we are handling concurrent adds and removes using an internal
> counter managed by fireEvent.
>
> By the way, as the GwtEventPreview interface is meant to address just this
> use case, would it work in your case? Not that we are implementing it right
> now, but it would be good to know if we have a working solution.
>
>
> Also, how important is having a protected widget createHandlers() method?
> Currently I've been talked out of it under the hypothesis it can be added
> later.
>
>
>
>
>
>
>
>
>
> On Tue, Nov 11, 2008 at 12:42 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>>
>> None that I can see. Kelly, I think you pushed for this clampdown. Still
>> want it?
>> rjrjr
>>
>> On Tue, Nov 11, 2008 at 9:41 AM, Ray Cromwell <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> I would prefer HandlerManager not be so finalized. I had a real use
>>> case for creating a version of fireEvent that dealt with DOM-like
>>> event bubbling for non-DOM events, the effect of freezing
>>> HandlerManager overrides would deny me the ability of creating a
>>> EventBubblingHandlerManager. Is there a good reason to prevent
>>> subclassing and overriding fireEvent?
>>> -Ray
>>>
>>>
>>> On Tue, Nov 11, 2008 at 8:28 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>>> > Do you have a proposal in mind? Everything we tightened down we had
>>> > good
>>> > reason to do so.
>>> > On Tue, Nov 11, 2008 at 11:17 AM, Ray Ryan <[EMAIL PROTECTED]> wrote:
>>> >>
>>> >> And as Emily and I just chatted offline, if we're loosening things up
>>> >> I'd
>>> >> rather see us allow folks to provide their own HandlerManager
>>> >> implementation
>>> >> (or wrapper around ours) than just try to predict the one or two hooks
>>> >> they'll find useful.
>>> >> rjrjr
>>> >>
>>> >> On Tue, Nov 11, 2008 at 7:59 AM, Emily Crutcher <[EMAIL PROTECTED]>
>>> >> wrote:
>>> >>>
>>> >>> We have made the fireEvents() final in handler manager and made it
>>> >>> impossible for users to replace the handler manager in widget, so I
>>> >>> think
>>> >>> this change would be necessary to preserve the full spirit of what
>>> >>> we've
>>> >>> been doing to upgrade the user's event system.
>>> >>>
>>> >>> However, we can tell people to use super-source to replace their
>>> >>> handler
>>> >>> manager class instead. It is not as clean of a solution, but it will
>>> >>> work,
>>> >>> and we can wait to see if anyone truly howls for this feature and put
>>> >>> it
>>> >>> into gwt 2.0 instead, then it can be a cool upgrade instead :-).
>>> >>>
>>> >>>
>>> >>> Cheers,
>>> >>>
>>> >>> Emily
>>> >>>
>>> >>>
>>> >>> On Tue, Nov 11, 2008 at 10:31 AM, Bruce Johnson <[EMAIL PROTECTED]>
>>> >>> wrote:
>>> >>>>
>>> >>>> Is this really part of the handler update? If this can wait, let's
>>> >>>> wait.
>>> >>>> We need to wrap up the changes to handlers ASAP.
>>> >>>> On Tue, Nov 11, 2008 at 9:37 AM, Emily Crutcher <[EMAIL PROTECTED]>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> I've managed to convince myself that it would be a trivial amount
>>> >>>>> of
>>> >>>>> work to introduce a GwtEventPreview interface into the events
>>> >>>>> package and
>>> >>>>> that the change would be a good one. In specific we would have:
>>> >>>>>
>>> >>>>> public interface GwtEventPreview {
>>> >>>>> boolean onGwtEventPreview(GwtEvent event);
>>> >>>>> }
>>> >>>>>
>>> >>>>> and, in HandlerManager:
>>> >>>>>
>>> >>>>> public void setGwtEventPreview(GwtEventPreview preview)
>>> >>>>>
>>> >>>>>
>>> >>>>> Then, in the final fireEvent method, if a preview has been
>>> >>>>> installed,
>>> >>>>> the event is routed through the preview first and is only fired if
>>> >>>>> the
>>> >>>>> preview returns true.
>>> >>>>> Can anyone think of any problems with this logic, any reason this
>>> >>>>> change would take more then a few minutes to create, or
>>> >>>>> any potentially better solutions which we might want to use
>>> >>>>> instead? As we
>>> >>>>> can certainly wait until GWT 2.0 to introduce something like this
>>> >>>>> if we can
>>> >>>>> think of any conceivable objections.
>>> >>>>>
>>> >>>>> Cheers,
>>> >>>>> Emily
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> "There are only 10 types of people in the world: Those who
>>> >>>>> understand
>>> >>>>> binary, and those who don't"
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >
>>> >
>>> >
>>> > --
>>> > "There are only 10 types of people in the world: Those who understand
>>> > binary, and those who don't"
>>> >
>>> > >
>>> >
>>
>>
>> >>
>
>
>
> --
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
