GWT ui:style how big of a bad idea (or not) is it to use it?

186 views
Skip to first unread message

Nuno Godinho de Matos

unread,
Aug 4, 2012, 10:40:23 AM8/4/12
to google-we...@googlegroups.com
Hi,
I am wondering how big a mistake is it to take advantage of the ui:style feature in ui binder interfaces?
Say your styles are all comprised within ui:style tags, and you always refer to them using the {style.XXXX} notation.
Now, on the browser, this shall all become obfuscated after gwt:compilation, the style name are not recognizable.
If we were to follow this approach for every style used on the application, wouldn't we also lose the potential of navigating the page dom with css selectors for example using library such as the Jquery gwt wrapper?
What's the policy here? 
One should never depend on the defined style names for executing, say, presentation logic such as collapsing dom elements?




Joseph Lust

unread,
Aug 4, 2012, 5:33:09 PM8/4/12
to google-we...@googlegroups.com
To start with CSSResource is awesome and I highly recommend using it. It forces you to program better. Should you really be trying to pull elements out of the page depending on their CSS names? Seems like a bad day if you ever want to rebrand or dress up your UI. If CSS is the graphical dressing of the site, separate those concerns from the functional aspects. Further, using those CSSResource interfaces keeps you from ever using string literals in your Java code or UiBinders, which is a best practice.

Additionally, with UI Automation tests our testers are tempted to use ugly selectors based on class names. This is a poor idea because then a class name changes a year later and 400 tests fail, even though functionally the site works just as well as before.

The real question here is what you want to do with your CSS. If you want to apply rules the site over, then don't use <ui:style>, but rather a CSSResource interface. This way that interface can be used by many widgets' UiBinders. However bespoke, small CSS tweaks do fit nicely into <ui:style> and you can always move them out to a CSSResource interface in the future if you want to use them multiple places. Note, from my experience you cannot well handle CSS inheritance/overriding between widgets with <ui:style>, but you can with standalone CSSResource interfaces.


Sincerely,
Joseph

Nuno Godinho de Matos

unread,
Aug 9, 2012, 2:15:29 AM8/9/12
to google-we...@googlegroups.com
Thank you all for your replies,

And In general I tend to agree that you should not promote tight coupling between your app functionality and the presentation styles.
On the other hand, Ryan Shillington, JQuery is javascript, but as you know most Great Jscript libraries jave wrappers for GWT. That is the case with jquery, http://code.google.com/p/gwt-jquery/. So yes, you can use JQuery from withing GWT.

Another thing is, 
say, for example that in page that you are rendered you have a list of row and each of these rows has a cless ODD or EVEN. Say that you want to hide away all ODD rows.
Why would it be best to have your GWT code traverse every single row in the set an based on your index % 2 decide weather or not collapse it, than have a CSS selector in gwt-jquery kill away all ODD rows?
Much less code!
I would normally live very well wich such a depencency, provided that if would be making my code use a CSS resource getter to find out the ODD classname.

My kindest regards,
Nuno.

Joseph Lust

unread,
Aug 9, 2012, 10:47:00 AM8/9/12
to google-we...@googlegroups.com
you have a list of row and each of these rows has a cless ODD or EVEN. Say that you want to hide away all ODD rows.
Why would it be best to have your GWT code traverse every single row in the set an based on your index % 2 decide weather or not collapse it, than have a CSS selector in gwt-jquery kill away all ODD rows?

Set a class 'odd' and 'even' and place those on each row when you make them. Then just use a CSS selector to show or hide all 'odd' rows by element.addClassName('hideOdd') on the parent container. Just a single operation in GWT.


Sincerely,
Joseph
Reply all
Reply to author
Forward
0 new messages