Ok, I understand better now. In that case I see no difference between:
new ButtonCell(myResources)
and
new ButtonCell(new DefaultAppearance(myResources))
I prefer the second one, as the first one does not make it obvious that:
new ButtonCell()
and
new ButtonCell(myResources)
lead to potentially different appearances. The first one using
DefaultAppearance2013 and the second using DefaultAppearance.
You say people will get to injecting the ClientBundle, but even if
they do that they are tied to the old appearance -- unless they change
the type of the injected ClientBundle wherever they use it. It's
clearer in code:
@Inject Provider<ButtonCell> buttonCellProvider;
@Inject Provider<DefaultAppearance.Resouces> resourcesProvider;
...
buttonCellProvider.get(); // Leads to DefaultAppearance2013
new ButtonCell(resourcesProvider.get()); // Leads to DefaultAppearance
If you inject the ClientBundle you cannot change the global appearance
simply by switching one binding. In other words: the convenience
constructor doesn't buy you anything.
(What you can do, however, is inject the appearance itself, and this
should be the recommended pattern given the fact that the ClientBundle
depends on the Appearance implementation.)
Cheers,
Philippe
On Mon, Feb 28, 2011 at 11:34 AM, John LaBanca <jlaba...@google.com> 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.
>
> On Mon, Feb 28, 2011 at 2:23 PM, Philippe Beaudoin
> <philippe.beaud...@gmail.com> wrote:
>>
>> On Mon, Feb 28, 2011 at 10:30 AM, Jeff Larsen <larse...@gmail.com> wrote:
>> >
>> > By forcing the user to do
>> >
>> > new DefaultAppearance(Resource)
>> >
>> > you're removing their ability to globally change the appearance. You've
>> > now
>> > introduced a much tighter coupling than was there previously. As a for
>> > instance, lets say I wanted different button styles, I go ahead and
>> > extend
>> > the ClientBundle and apply then everything gets styled to my liking.
>> > Now lets say there is some html5 new button hotness that we want to have
>> > access to, or we need to add different Aria support etc. I can swap out
>> > the
>> > Appearance class globally with deferred binding by keeping both
>> > constructors
>> > in its current form. By getting rid of the constructor, I have to find
>> > every
>> > instance of my classes and change them programmatically to not use
>> > DefaultAppearance, but the new appearance. Now I'm good and I'm in a
>> > even
>> > more difficult refactor if I need to change the appearance based on
>> > locale/browser etc.
>>
>> In its current form, I don't think the constructor accepting a
>> CssResource lets GWT swap the default appearance without impacting the
>> user's code that relies on it. Let's look at your proposed
>> implementation for the constructor in question:
>> // Replace the styles used by this cell instance.
>> public ButtonCell(DefaultAppearance.Resources resources) {
>> this(new DefaultAppearance(resources));
>> }
>>
>> This constructor is not using deferred binding. Therefore, if you want
>> user's code relying on it to switch to the new appearance you have to
>> roll-out a new implementation of the constructor. Let's say you do
>> that:
>> // Replace the styles used by this cell instance.
>> public ButtonCell(DefaultAppearance.Resources resources) {
>>
>> this(new NewDefaultAppearance(resources));
>> }
>>
>> The problem, here, is that you are passing DefaultAppearance.Resources
>> to NewDefaultAppearance. It means that your new appearance
>> implementation cannot use CSS classes that did not exist in the
>> original CssResource. In fact, in the current implementation, the
>> CssResource is defined by the Appearance _implementation_ (it's
>> DefaultAppearance.Resource, not Appearance.Resource).
>>
>> The confusion therefore is:
>> a) Will ButtonCell(DefaultAppearance.Resources resources) update its
>> appearance automatically when GWT upgrades to a new default
>> appearance; OR
>> b) Will it bind me forever to DefaultAppearance?
>> My proposition of dropping it was assuming you wanted to go with (b),
>> now I understand that you want the behavior of (a) -- which I agree is
>> much preferable -- but the current design does not seem to allow for
>> that goal. Maybe we should discuss ways to decouple the CssResource
>> from the Appearance implementations instead?
>>
>> Also: I agree with the rest of your post and your reasoning.
>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
