Thomas Broyer wrote: > Finally, I don't really like the Widget suffix naming convention, that's > what "namespaces" (packages in Java) are for (tell a Button from another > Buton), but I sure could live with it. > I already have those "naming conflicts" using Guava and gwt-dev –which > includes a rebased, olderguava–, and some other library that transitively > depends on a rebased Apache Commons, in the same project (so I have many > "Lists" classes to choose from; not to mention java.util.List vs. > jaa.awt.List, and java.util.Date vs. java.sql.Date). When I'm angry that > eclipse always pick the wrong one by default, I configure it so it ignores > the others when suggesting completions. Or maybe the GPE could plug into > Eclipse to make it prefer the "new" Button so it's always displayed before > the "old" one in such autocomplete or "organize imports" lists? >
+1 for right name, different package (and aggressive deprecation, please). On Thu, Feb 24, 2011 at 7:30 PM, Thomas Broyer <[email protected]> wrote: > I support the overall idea. > A few notes though: > I'm worried about the events in the ButtonCell example. If they're just > there to provide hooks to inject styles, then: > > you probably don't need them if you use a "native button" appearance; which > means you're listening to events but doing nothing in response to them; and > we now too many registered events are bad for performance (that's what lead > to the "event delegation" pattern, taking advantage of event bubbling, > right?) > why couldn't you just use :hover, :active and similar pseudo-classes? > > OK, maybe the ButtonCell is not the best example, as its appearance > and behavior are quite… limited, but still. > Or could, in this case, the Appearance have hasHoverBehavior or similar that > the Cell would use to decide which events it's interested in? (so if you > want your onHover method to be called, you'd first have to override > hasHoverBehavior to return true). As an alternative, a few such behaviours > could come in "mixin" interfaces, and the Cell would advertise (in the > javadoc) which ones it supports (the ButtonCell would then only say it > handles "mouseover" events if the Appearance is an instanceof HasHover). > > > You wrote: > > Finally, note that Appearance is an abstract class. This allows us to add > more state logic in the future without breaking existing Appearances. For > example, we could add new methods "setRightFlush()" and "setLeftFlush()" > which would make the right and left edges of the button flat, such that they > could be lined up next to each other. Existing appearances may not support > the new feature, but they would still work. > > This is not exactly true: > > Since the new method is probably something "obvious" I might already have > implemented it. This is really evil because my code might still compile but > not work any more. > > — > Source: https://groups.google.com/d/msg/google-guice/rV21c_HQivk/NLUNASfhHq8J > See also in the same thread: > https://groups.google.com/d/msg/google-guice/rV21c_HQivk/mI6JP206-tsJ > > > You wrote: > > Some Cells support methods to change how the Cell is rendered. For example, > ButtonCell could provide a setTabIndex() method to set the tab index of the > element. ButtonWidget would expose the same methods and forward through to > the Cell. > > Does it mean there could finally be a "Button" interface (implemented by > both ButtonCell and ButtonWidget) as a few people have asked > for: http://code.google.com/p/google-web-toolkit/issues/detail?id=5275 > > Finally, I don't really like the Widget suffix naming convention, that's > what "namespaces" (packages in Java) are for (tell a Button from another > Buton), but I sure could live with it. > I already have those "naming conflicts" using Guava and gwt-dev –which > includes a rebased, olderguava–, and some other library that transitively > depends on a rebased Apache Commons, in the same project (so I have many > "Lists" classes to choose from; not to mention java.util.List vs. > jaa.awt.List, and java.util.Date vs. java.sql.Date). When I'm angry that > eclipse always pick the wrong one by default, I configure it so it ignores > the others when suggesting completions. Or maybe the GPE could plug into > Eclipse to make it prefer the "new" Button so it's always displayed before > the "old" one in such autocomplete or "organize imports" lists? > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
