BTW, I'm also curious as to the performance implications. A subtype of
HandlerManager with override fireEvent() could theoretically be
type-tightened and staticified, even inlined, because the field inside
the calling widgets can typically be declared with a concrete leaf
type (MyHandlerManager manager = ...). With the event preview
mechanism, the dispatch will always be doubly indirect with
null-checks, plus if more than one implementation of the interface
exists that is reachable from module entry point, type tigthening will
be hampered and it will always be a polymorphic dispatch.
-Ray
On Tue, Nov 11, 2008 at 11:30 AM, Ray Cromwell <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
