1. Its more API clutter Yep, the question is it useful api clutter. 2. Can't users just add listeners directly to their widgets that they put into the tabs?
Not necessarily, the tabs maybe added via some sort of injection dependency. For instance, extra functionality, including tabs, are often added based upon the groups a user belows to. So, when the programmer wants to use a custom keyboard navigation on her tab panel, she would have to go into places scattered throughout the code base in order to convert all of the tabs to widgets which support keyboard events and add her handlers there. 3. We have a lot of widgets that "wrap" content. Will they all have wrappers? Not unless there is a compelling reason for them to do so. Here, we are replacing functionality that already allows users to access these internal widgets through the onKeyDown() and onClick() public methods. Now, when there is a compelling reason, we would be exposing sub-parts using get*Wrapper which returns a characteristic interface, so if this is the wrong pattern, we should figure it out before we publish it! 4. I think this is too implementation specific to make public. The fact that we wrap tabs in a ClickDecoratorPanel so we can catch events and style them is just an implementation. We could just as easily (well, not as easily) catch events on the outer element and determine where the event occured. Completely agreed, that is why rather then exposing ClickDecoratorPanel we are exposing a characteristic interface instead. P.S. Ray wins a cookie because he was right about you having an opinion on this :-). On Tue, Nov 11, 2008 at 10:43 AM, John LaBanca <[EMAIL PROTECTED]> wrote: > At first glance, I don't see the need for a public TabWrapper interface. > Can you tell me what the use case is for this? My main concerns are the > following: > 1. Its more API clutter > 2. Can't users just add listeners directly to their widgets that they put > into the tabs? > 3. We have a lot of widgets that "wrap" content. Will they all have > wrappers? > 4. I think this is too implementation specific to make public. The fact > that we wrap tabs in a ClickDecoratorPanel so we can catch events and style > them is just an implementation. We could just as easily (well, not as > easily) catch events on the outer element and determine where the event > occured. > > But, since you obviously thought this out, I'm sure I'm missing some key > point. > > Thanks, > John LaBanca > [EMAIL PROTECTED] > > > > On Mon, Nov 10, 2008 at 8:16 PM, Ray Ryan <[EMAIL PROTECTED]> wrote: > >> (Reviving the old Response Requested meaning of RR--there is no patch >> here, but rather a design question.) >> >> Take a look at the new TabWrapper getTabWrapper(int index) method on >> TabBar in the 1_6_clean_events branch: >> >> >> http://code.google.com/p/google-web-toolkit/source/browse/branches/1_6_clean_events/user/src/com/google/gwt/user/client/ui/TabBar.java >> >> See that interface it returns, TabWrapper extends HasAllKeyHandlers, >> HasClickHandlers? Emily and I would like to make that more useful without >> necessarily committing to it being a Widget. >> To that end, we'd like to introduce a new interface, HasElement, which >> will hold most or all of the public API of UIObject. We'd make similar use >> of the interface for DialogBox#getCaptionWrapper(), and one or two other >> places that I hope Emily will remind me of. >> >> Any objections or warnings before we go ahead and make the change? >> >> rjrjr >> >> > > > > -- "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 -~----------~----~----~----~------~----~------~--~---
