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: 1. 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?) 2. 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<http://lekkimworld.com/2007/11/01/sick_of_java_awt_type_ahead_suggestions_in_eclipse.html>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
