CssResource + Custom Deferred Binding?

[shawnjohnson]

Is it possible to use CssResource @eval with a static method AND
deferred binding? As you can guess, this isn't working so far, but
I've never tried my own deferred binding before, so I may be missing a
step.

I am trying to do something like this:
<replace-with class="com.mycompany.client.ui.CssGradientUtil">
<when-type-is class="com.mycompany.client.ui.CssGradientUtil"/>
</replace-with>

<replace-with class="com.mycompany.client.ui.CssGradientUtilIE7">
<when-type-is class="com.mycompany.client.ui.CssGradientUtil"/>
<when-property-is name="user.agent" value="ie6" />
</replace-with>

--------------------------------------
Css or UiBinder class:

@eval mybuttonGradient
com.mycompany.client.ui.CssGradientUtil.getLinearGradient("#a0d8fb","#55afea");
.myButton{
background: #a0d8fb;
background: mybuttonGradient;
}

[Colin Alworth]

You can't replace the static method through replace-with, but you can make the static methods call GWT.create on a class that has one implementation, and use replace-with to swap in another one. For example, om.mycompany.client.ui.CssGradientUtil.getLinearGradient could be a static method that looks like

    CssGradientUtil util = GWT.create(CssGradientUtil.class);
    return util.getGradient(...);

To make that work, have getGradient be a non-static method, overridden in CssGradientUtilIE7. GWT.create will go through the rebind rules and create an instance that fits best, and you can use normal java inheritance to get the overridden method.

There is no need for the first replace-with block, that replaces a class with itself.

[Ed]

You can, but I advice you to use an static/instance class couple in this case

.

Let me explain by a Theme example I use:

In my Css:

@eval headerEntryFontColor com.test.AmountListPreferencesBridge.headerEntryFontColor();
.HeaderEntry {
color: headerEntryFontColor;
}

AmountListPreferencesBridge is the static class that contains an instance of the target class that contains the CSS styles:

private static final AmountListPreferences BRIDGE = GWT.<AmountListPreferences> create(AmountListPreferences.class);

 

public static AmountListPreferences getBridge() {
return BRIDGE;
}

public static String headerEntryFontColor() {
return getBridge().headerEntryFontColor();
}

And in the gwt file theme.standard.Standaard.gwt.xml (that is included in my main gwt file and can be replaced by another theme gwt xml to change theme's):

<replace-with class="com.test.theme.standard.StandardAmountListPreferences">
<when-type-is class="com.test.widgets.amountlist.resources.AmountListPreferences" />
</replace-with>

[shawnjohnson]

That worked exactly as needed, Thank You Colin!

[shawnjohnson]

Ed, thanks for your suggestion. Might be more than I can handle at
this point. We don't really need themes, though I don't think that's
your point. Regardless, I'll refer back to this later as I get
further in this process.

[Colin Alworth]

I'm fairly certain that the compiler will figure out that those methods return constants and will either optimize them out, or at least turn them into static methods anyway, so a singleton isn't going to buy you too much. If you like the code style, that's one thing, but at least in other cases like this, the compiler is smart enough to do the right thing.

[Ed]

>   so a singleton isn't going to buy you too much.

What do you mean?

[Colin Alworth]

I thought you were suggesting the static/singleton part here by way of suggesting that this was a better way of doing things, avoiding constructing the same instance over and over, but in retrospect I might have misunderstood. If you are suggesting the static/singleton stuff to make it easier to add on more methods, then yeah, that makes perfect sense.

My only point was meant to be from the optimization perspective, that the compiler is smart enough to get the job done just about any way you write it.