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). 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! On Jan 3, 9:29 am, Thomas Broyer <[email protected]> wrote: > On Jan 3, 6:42 am, jarrod <[email protected]> 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. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
