I agree. I think sometime soon when I get some bandwidth I can provide
some mock container/component classes to demonstrate the desired use
case (say, a structured canvas drawing application ala Visio or
Lombardi)
-Ray
On Tue, Nov 11, 2008 at 12:38 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
