I don't really understand you Stack proposal is the HandlerManager is
already a map to hold different type of listeners and like Thomas
explained above you can influence the source.

The Concurrent access exception I already solved as I had my own
Listener Collection base that all listener collection extended. They
control did and did already the necessary queueing like now
implemented in the HandlerManager. Or just throw an exception when
concurrent access toke place, or the maximum number of listeners
exceeded, or a listener already existed, etc.... Many little things
that make it very easy to find bugs...
My actual Collection listener implementations where almost empty and
just a subclass with some generic specification... that's it, nothing
BIG like you mentioned.

I understand that the GWT don't want to create a lock-in situation and
hide the creation of the HandlerManager such that can easily change
this behavior in the future... But is this really an advantage and the
correct way ??.. Why not just let this open and still change this
behavior ??... I/We have to make changes anyway.. In my case:
Option 1: produce many code to code around the situation that my own
HandlerManager can't be injected as explained in:
http://code.google.com/p/google-web-toolkit/issues/detail?id=3628&q=HandlerManager

Option 2: My own HandlerManager can be  injected which saved my the
bunch of code from option 1.

Either way: if the gwt team decides to change this HandlerManager
behavior, I have to deal with these changes anyway and in option 2,
this takes less time and result in less code modifications. So what's
the difference??
The same kind of "coding around" I see in other gwt frameworks like
gxt... (they have to change/changed a lot to support 1.6)...

So please, help me understand why the gwt dev team make these things
hidden for gwt developers??...  As I don't see any advantage of hiding
these kind of implementation details.

I am talking about "implementation details" in general as there are
more of these situations (can be found in this or the contributor
forum, like primitive intercaces...) and it sometimes very frustrating
when you want to implement complex functionality that is so simple in
swt and swing and not in gwt as they "still" choose to hide these kind
of details :(... (not because it's not possible)....

My experience and advice: please just make GWT more open and
extentable.. ... ?

-- Ed



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to