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
