Inconsistent behavior of setStyleName(), setPrimaryStyleName() and addStyleName() on new layout widgets
jarrod
particular), I noticed
that older widgets, such as HTML, automatically set a default primary
style name in the
constructor, while the DockLayoutPanel does not.
This isn't terrible in and of itself, but in my UiBinder template, I
have the following code:
<g:DockLayoutPanel styleName="{style.main}"
addStyleNames="{global.style.html}" unit="PX">
...
</g:DockLayoutPanel>
When UiBinder generates the code for this element, the order of
attribute processing is not
preserved, and the resulting code is as follows:
f_DockLayoutPanel1.addStyleName("" + global.style().html() + "");
f_DockLayoutPanel1.setStyleName("" + style.main() + "");
Because "setStyleName()" is called second, the previously added style
names are blown away.
Additionally, for whatever reason, changing the "styleName" attribute
on my DockLayoutPanel to
"stylePrimaryName" yields exactly the same results. Yet on a <g:HTML /
> element, the
combination of "stylePrimaryName" and "addStyleNames" works as
expected.
~~~~~~~~~~~~~~~~
I posted this as an issue over at the GWT project site:
http://code.google.com/p/google-web-toolkit/issues/detail?id=4435
The ticket includes a GWT project attachment with a failing unit test.
Thomas Broyer
On Jan 3, 6:42 am, jarrod <jarrod.carl...@gmail.com> wrote:
> While working with some of the new Layout widgets (DockLayoutPanel in
> particular), I noticed
> that older widgets, such as HTML, automatically set a default primary
> style name in the
> constructor, while the DockLayoutPanel does not.
>
> This isn't terrible in and of itself, but in my UiBinder template, I
> have the following code:
>
> <g:DockLayoutPanel styleName="{style.main}"
> addStyleNames="{global.style.html}" unit="PX">
> ...
> </g:DockLayoutPanel>
>
> When UiBinder generates the code for this element, the order of
> attribute processing is not
> preserved, and the resulting code is as follows:
>
> f_DockLayoutPanel1.addStyleName("" + global.style().html() + "");
> f_DockLayoutPanel1.setStyleName("" + style.main() + "");
>
> Because "setStyleName()" is called second, the previously added style
> names are blown away.
Well, why are you using *both* styleName and addStyleNames? why not
stick with only one? either styleName="{style.main}
{global.style.html}" or addStyleNames="{style.main}
{global.style.html}" (note that the first one is processed as a single
value passed directly to setStyleName while the second is parsed as a
list of tokens, calling addStyleName repeatedly).
(That being said, I agree this should be considered a bug,
addStyleName and addStyleDependentName should be called after setters,
but I don't know if this can be fixed easily, without having to change
UiBinder's internals too much)
> Additionally, for whatever reason, changing the "styleName" attribute
> on my DockLayoutPanel to
> "stylePrimaryName" yields exactly the same results. Yet on a <g:HTML /> element, the
>
> combination of "stylePrimaryName" and "addStyleNames" works as
> expected.
That's because setStylePrimaryName works by replacing the very first
class and then replacing the equivalent prefix in the following
classes. Because the HTML widget has a default style name of gwt-HTML,
setting stylePrimaryName will replace gwt-HTML with the new value, and
leave the {style.main} and/or {global.style.html} as-is; while on
DockPanelLayout the addStyleNames="" will actually set the "primary
name" (as there's no pre-existing default style name), so
setStylePrimaryName will take the first addStyleNames value as the
"primary name" and replace it.
jarrod
in some cases, it is desirable to remove any existing, default styles
from the widget (in the case of HTML) before adding my own custom
styles. For this to be effective, I imagine I would have to use
setStyleName or setStylePrimaryName. However, in addition to the
primary style, I also have a need to set a few additional styles on
the widget, and thus the use of addStyleNames for the extra names.
While I probably could get away with passing all of the styles at once
to setStyleName or setStylePrimaryName, doing so feels like a
violation of the method's contracts (according to the docs).
The real point at hand is that the dual use of setStyleName and
addStyleNames is inconsistent between different widget types. I don't
think UI developers should have to think about how to set a style name
for a widget based on what kind of widget it is.
Thanks for the explanation, though!
Thomas Broyer
On Jan 3, 5:24 pm, jarrod <jarrod.carl...@gmail.com> wrote:
> Using both "setStyle" and "addStyleNames" isn't a necessity. However,
> in some cases, it is desirable to remove any existing, default styles
> from the widget (in the case of HTML) before adding my own custom
> styles. For this to be effective, I imagine I would have to use
> setStyleName or setStylePrimaryName. However, in addition to the
> primary style, I also have a need to set a few additional styles on
> the widget, and thus the use of addStyleNames for the extra names.
>
> While I probably could get away with passing all of the styles at once
> to setStyleName or setStylePrimaryName, doing so feels like a
> violation of the method's contracts (according to the docs).
It would be a violation of setStylePrimaryName, but clearly not of
setStyleName (on the contrary!)
> The real point at hand is that the dual use of setStyleName and
> addStyleNames is inconsistent between different widget types.
No, if setStyleName is called after addStyleName, it'll result in the
same style name in the end (the one passed to setStyleName), whichever
the widget (even if it has a default/primary style name, as
setStyleName will also clear it).
Use of both addStyleNames and setStylePrimaryName though gives
different results depending on whether the widget already has a
default/primary style name, and I agree this should be changed if it
is easily possible (though it's not worth completely refactoring the
UiBinder just to change this edge-case behavior)
> I don't
> think UI developers should have to think about how to set a style name
> for a widget based on what kind of widget it is.
Yes, but I don't think UI developers should use both "set" and "add"
on the same widget either.