-1
Why? What problem is this fixing?
http://gwt-code-reviews.appspot.com/138801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Sorry, I came in mid-conversation. My -1 was in defense of
setHandlerManager(), seeing no harm in allowing a widget to swap around
its HM if it wants to.
I'm totally in favor of allowing a custom HM to be used.
http://gwt-code-reviews.appspot.com/138801
--
http://groups.google.com/group/Google-
Sven had a use case for doing this that we talked about in another thread
(which I just forwarded to gwt-contrib):
https://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/888ae5ec54a7a8da
Basically, he has a more advanced HandlerManager that he wants to use. We
told h
I am against the wimpy runtime assertion in Sven's patch, since
assertaions may be disasbled. I think that swapping out a
HandlerManager is inviting problems for developers, and I can't think of
a good use case for it. If we are only going to allow one
HandlerManager, it should be baked into the
If you're right that swapping HMs midstream is a bad idea, I think you need
a better argument than "it's a bad idea." What's the actual danger? If I'm
making my own HM I'm already pretty savvy. Why tie my hands?
But yes, if you win that point, I agree with the change to replace setHM(HM)
with HM c
Warning: better arguments against setHandlerManager below:
My concern is that it is too easy to add handlers to a Widget and then
set a new HandlerManager, expecting the old handlers to be transferred
to the new HandlerManager. What would be the correct thing to do here?
We can't transfer handle
On Tue, Feb 9, 2010 at 9:09 AM, wrote:
> Warning: better arguments against setHandlerManager below:
>
> My concern is that it is too easy to add handlers to a Widget and then
> set a new HandlerManager, expecting the old handlers to be transferred
> to the new HandlerManager. What would be the c
As a developer I absolutely agree with Mr. Ryan here... I hope that
this isn't taken the wrong way, but it's so difficult to customize any
given tool that GWT hands us. The eventual answer always seems to be
"make a custom build" which is extremely hard to sell to anyone other
than a GWT developer.
Yes, many times its too hard to customize things. Sometimes it make
sense to use private or package protected. But i think the
HandlerManager gets used so widely that it should be customizable
On 9 Feb., 23:57, Nathan Wells wrote:
> As a developer I absolutely agree with Mr. Ryan here... I hope t
The danger is that if you add handlers, and than later in your code
call setHandlerManager with a new HandlerManager. If we dont check for
a prior existing HandlerManager, all old HandlerRegistration's will be
lost. If you dont know what happened, you will search forever why your
old handlers are n
On 2010/02/09 16:46:27, Ray Ryan wrote:
Sorry, I came in mid-conversation. My -1 was in defense of
setHandlerManager(),
seeing no harm in allowing a widget to swap around its HM if it wants
to.
I'm totally in favor of allowing a custom HM to be used.
For the ListModel also an own HandlerRe
On 10 Feb., 16:28, Ray Ryan wrote:
> Sven, you're arguing both sides here. You want things to be more
> customizable in general, but with your specific patch you're trying to be as
> restrictive as you can to achieve your personal goal.
Both patches have the same restriction, once a handlermana
I'd say that if you wanted to implement a HandlerManager stack, it
would probably be best to do that internal to the HandlerManager,
rather than forcing a Widget to know how events are handled.
Assuming that is possible given the current Widget implementations
(others more expert than I would know
Updated the patch to only add a createHandlerManager which gets called
by ensureHandlers.
On 12 Feb., 04:22, John LaBanca wrote:
> Alright, lets go with createHandlerManager() for now. Thanks for all the
> feedback.
>
> @sven -
>
> Would you like to update the patch by reverting the getHandlerMa
Hi Ray, all,
I believe changing HMs mid stream is dangerous:
1. Say your (nav & edit) widget fires events that are common to both modes
(i.e. a simple onOpen) and the widget is by default in nav mode
2 Say A registers an onOpen handler (which gets added to hm1 -- the default
HM) then later switc
Sven, you're arguing both sides here. You want things to be more
customizable in general, but with your specific patch you're trying to be as
restrictive as you can to achieve your personal goal.
I'm assuming that if we provide an unrestricted setHandlerManager we would
also provide a getHandlerMa
My last two cents:
This discussion is a classic example of why the GWT widgets are so locked
down. GWT Contributors, do you trust yourselves or don't you?
On Wed, Feb 10, 2010 at 7:27 AM, Andi Mullaraj wrote:
> Hi Ray, all,
>
> I believe changing HMs mid stream is dangerous:
>
> 1. Say your (nav
On Wed, Feb 10, 2010 at 10:27 AM, Andi Mullaraj wrote:
> I believe changing HMs mid stream is dangerous:
>
> 1. Say your (nav & edit) widget fires events that are common to both modes
> (i.e. a simple onOpen) and the widget is by default in nav mode
> 2 Say A registers an onOpen handler (which get
I still think my proposal solves this for both cases. We add a protected
createHandlerManager, which is more restrictive because it is only called
once per widget.
We also make getHandlerManager() protected, which allows users to replace
the HandlerManager if they really want to by overriding get
I forgot about that nuance of your proposal. I like.
@jat: the stack idea is nifty, but expanding the scope of the patch even
worse than I am. And JL's proposal would let one implement that.
On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca wrote:
> I still think my proposal solves this for both ca
On Wed, Feb 10, 2010 at 10:56 AM, John LaBanca wrote:
> We also make getHandlerManager() protected, which allows users to replace
> the HandlerManager if they really want to by overriding getHandlerManager to
> return one of many. It would be up to the developer to add a
> setHandlerManager() me
@John: hm2 could indeed handle onOpen and hm1 would never get a chance to
notify its registered handlers :(
So I'd gues the event has to be pushed down in all cases ... which pretty
much takes us to "one" HM setup.
I also think that createHM is enough.
In general, though components usually have s
The argument seems to revolve around changing HandlerManagers
resulting in the loss of registered handlers. Is it possible that the
HandlerManager and the set of registered handlers aren't really the
same thing and need to be separated? Would everyone be happy if you
could call setHandlerManager()
But what if you have the case where you're setting the HandlerManager
specifically because you want to stop listening to all the events from
the previous HandlerManager. The idea of a stack of HandlerManagers
makes some sense if you want to have different HandlerManagers
handling events for differe
I think that violates the spirit, if not the letter, of the
addHandler() contract. I add a handler and I get back a
HandlerRegistration. I can use that registration to remove the handler
later, if I choose to do so. If I expose that registration to other
code, then the other code can also remove th
This conversation keeps getting complicated by discussions of policy. I'm
just trying to make it possible for widgets we haven't thought of yet to
define policies of their own.
E.g., to temporarily switch between modes that change the set of events they
source, copying some handlers or not if that
> Am I trying to provide flexibility that no one is asking for?
In my opinion, this is providing flexibility that is not necessary and
is not a net positive change to the API. I'm not convinced that it's
the right thing to do. However if you were to provide that
flexibility, I would agree that get
I don't get that. If I (widget) have nothing to say to you for a while (am
not going to be generating the kinds of events that you are registered for),
why do you care if my mechanism for achieving that involves putting my usual
HM on ice? So long as I don't cause an error if you de-register in the
I don't get why it would be necessary. What would you be able to do by
putting an HM "on ice" that you can't do with the existing API? Why
complicate things? Where's the use case that requires this new API?
Is this just a philosophical argument over narrowly defined, tightly
controlled APIs vs. mo
Your point being that I could just implement a custom handler manager that
can do any of these things, and so should keep Widgets that much simpler,
yes? I don't have a good answer to that.
On Thu, Feb 11, 2010 at 10:54 AM, Isaac Truett wrote:
> I don't get why it would be necessary. What would
I was actually thinking it would involve overriding onBrowserEvent().
Maybe I need to have another look at how HandlerManager fits into
things. I thought of it more as a dispatcher directing traffic than
the actual source of event firing. But yes, essentially, it looks like
all of the tools are the
If you need to swap out two different complex event handling modes of
a widget (where say, a half dozen different events are being
monitored), I think it is too complex to remove all the old handlers
and add new ones every time, I also think overriding onBrowserEvent is
kind of tedious and limited,
But I could still override createHM to be a wrapper that is backed by two
separate instances, for example. I'm running out of rationalizations for
providing both methods. And if getHM is missed it could be added later.
180 degrees,
rjrjr
On Feb 11, 2010 1:00 PM, "Ray Cromwell" wrote:
If you nee
Does anyone object to adding createHandlerManager now, and then adding
getHandlerManager if it is needed later?
Thanks,
John LaBanca
jlaba...@google.com
On Thu, Feb 11, 2010 at 4:09 PM, Ray Ryan wrote:
> But I could still override createHM to be a wrapper that is backed by two
> separate insta
I agree, you could do it that way. I'm trying to think of a case where
it wouldn't be good enough, I guess in theory, you could have a widget
that can't be subclassed/overridden where set/get methods could allow
you to override or inject HM dependencies, whereas the create
technique isn't as DI fri
@John - No objection here.
@Ray squared - The idea of overriding HandlerManager still intrigues
me. I've never found myself wanting to do it and I don't recall seeing
it in practice elsewhere. I'm curious. If either of you knows of a
project where I could find an example, would you mind passing al
Alright, lets go with createHandlerManager() for now. Thanks for all the
feedback.
@sven -
Would you like to update the patch by reverting the getHandlerManager()
method back to a package protected method? If you don't get to it for a few
days, I'll can do it for you.
Thanks,
John LaBanca
jlab
Thinking outload...
What about allowing ctors to take a HM. The other ctors use the default
implementation. If you dont care for a HM then use the ctors without HM in
the parameter list. That way you dont pollute the widget method list with
gets/creates and sets which prolly dont make sense once t
>
> Thinking outload...
>
> What about allowing ctors to take a HM. The other ctors use the default
> implementation. If you dont care for a HM then use the ctors without HM in
> the parameter list. That way
The problem with this is that you then have to add HM to the ctor for every
extension of
39 matches
Mail list logo
