What is clear is that this is a use case that needs to be addressed before
1.6 ships. However, I think it will actually be a lot easier to talk about
after the initial patch lands in 1.6/trunk and is therefore more visible to
all our users.
Cheers,
Emily
On Tue, Nov 11, 2008 at 3:00 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> If you did not have an event preview defined, then it is only a null check,
> which are cheap.
>
> If you did have one defined you would have had to have two implementations
> of fireEvent and your inherited version had better call our fireEvent
> somewhere or else your add/remove handler code will break in mysterious
> ways, so you will still have the same number of dispatches.
>
>
>
>
>
> On Tue, Nov 11, 2008 at 2:34 PM, Ray Cromwell <[EMAIL PROTECTED]>wrote:
>
>> 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"
>> >>
>> >
>>
>
>
>
> --
> "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
-~----------~----~----~----~------~----~------~--~---
