Sorry for the long delay. I just read through the email chain and tried to encapsulate the common concerns below:
*Appearance: abstract class or interface* **I still think Appearance should be an abstract class. tbroyer is correct that adding a method might be a breaking change for some apps, but thats better than guaranteeing a breaking change. Adding a method to an interface also has the same problem that users might already implement the method and not realize the change, so I don't see any advantage of using an interface. We can document the fact that we may add methods to Appearance from time to time. *DefaultAppearance.Resources constructor is bad* I agree that these constructors might confuse users because they might not realize that using it precludes their apps from getting the latest version of Appearance. We can remove them for now. If users ask for us to add them later, we can always do so. *Hover methods* I agree that using :hover styles is better than catching mouseover/out events and styling manually. In general, we want to leverage CSS as much as possible to improve performance. I'm going to start implementing this and see how far I get. Thanks, John LaBanca [email protected] On Mon, Feb 28, 2011 at 4:10 PM, Philippe Beaudoin < [email protected]> wrote: > > On Monday, February 28, 2011 12:42:30 PM UTC-8, John LaBanca wrote: >> >> On Mon, Feb 28, 2011 at 3:14 PM, Jeff Larsen <[email protected]> wrote: >> >> >>> >>> On Mon, Feb 28, 2011 at 1:34 PM, John LaBanca <[email protected]>wrote: >>> >>>> Let me clarify what I had in mind for replacing the default GWT >>>> appearance. In the future, we might add a new DefaultAppearance >>>> implementation, but would leave the existing one. We would probably give >>>> it >>>> some trendy name, like ModernAppearance or DefaultAppearance2013, leaving >>>> DefaultAppearance. The GWT deferred binding for Appearance would be >>>> changed >>>> to point to DefaultAppearance2013. >>>> >>>> Using the default constructor will result in being automatically >>>> upgraded to the new appearance: >>>> new ButtonCell(); // Always uses the most recent Apperance. >>>> >>>> Using the Resources convenience constructor will use the old Appearance. >>>> new ButtonCell(myResources); // Uses DefaultAppearance. May be >>>> deprecated when new appearances are added. >>>> >>>> We would add a new convenience constructor for the new Appearance: >>>> public ButtonCell(DefaultAppearance2013.Resources resources); >>>> >>>> There is no way around the fact that DefaultAppearance.Resources are >>>> tied to DefaultAppearance and won't carry over to the new >>>> DefaultAppearance2013. >>>> >>> >>> That wouldn't have to be the case though would it? >>> >>> Couldn't we stick the Resource in the Appearance, then if the new >>> DefaultAppearance2013 for Button doesn't need to add new css definitions, >>> there then is no need to add an additional constructor or change up the >>> style definitions. Should something happen where DefaultAppearance2013 needs >>> additional classes you still have the option of creating a new ctor for that >>> new theme, you've just given yourself some more options down the road. The >>> main drawback here is that the Appearance.Resources may have css classes >>> that are unused in descendant appearances. If that burden seems too high, >>> then there still is nothing stopping you from implementing the multiple ctor >>> solution. >>> >> Thats actually a big problem. DefaultAppearance.Resources may specify a >> background gradient image, but in the future we can use CSS to specify a >> background gradient. So, we end up with an unused image and users are >> confused about why the gradient doesn't apply. Worse, if we want to add a >> style name or resources to the interface, thats a breaking change. >> >> Still, if DefaultAppearance2013 is a minor change that uses all of the >> same style names, we could subclass Appearance and use the same Resources. >> It would depend on how much of a change we make to the DOM structure. >> > > I agree, I think defining the ClientBundle outside the Appearance > implementation is a bit smelly... But, IMHO this smell is still present in > the constructor accepting a DefaultAppearance.Resources, and the > constructor-explosion problem mentioned by Jeff tends to confirm it. I think > we should acknowledge that ClientBundle depends on the Appearance > implementation and invite users to inject Appearance rather than the > ClientBundle. > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
