GWT CSS Style Annotation

[Danial]

As my attempt to make CSS easier to be used in my GWT project I came
up with using java annotations for css styles.
Please check out this project: http://code.google.com/p/gwt-style-annotation/

It is much cleaner than a big .css file or cluttering your code with
getElement().getStyle()...
All the annotations will be parsed and added to a .css file at compile
time transparently.

Let me know what your think.

Thanks,

Danial

[Juan Pablo Gardella]

Very Good! Thanks for sharing 

2011/11/23 Danial <danial...@gmail.com>

Danial

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[cd]

I actually wonder why one would want to include style in the gwt code.
Didn't we want separation of concerns, and keep style and code as much
separated as possible? In that case, I would think a separate
stylesheet is in most cases the best answer, so a person with a
designer role will be able to style the gwt app as he/she likes,
without need to recompile in-code styles.

Am I old-fashioned? :-)

Erwin

[Vitrums]

This approach will bind your hands in further attempts to make any look&feel overhaul. For some flexibility, try to use compile time constants for annotation values. E.g. you've got some interface Styles, which might extend an interface ThemeMoonsky or interface ThemeSunshine not inclusive:

/** Theme 1 */

interface ThemeMoonsky extends BasicStyles {

    String BODY_BACKGROUND_COLOR = "#333";

}

/** Theme 2 */

interface ThemeSunshine extends BasicStyles {

    String BODY_BACKGROUND_COLOR = "#F0F";

}

/** Some very generic styles */

inteface BasicStyles {

    String BODY_TEXT_COLOR = "black";

    String HEADER_FONT = "18px bold sans-serif blue"; 

}

/**

 * You styles interface, where you get all constants from.

 * Extend ThemeSunshine to have your site restyled

 */

interface Styles extends ThemeMoonsky {

    // Empty body

}

somewhere in your code:

        @Background(Styles.BODY_BACKGROUND_COLOR)
        protected Widget getLabel() {
                return label;
        }

Well, you get the idea. But it's still not amenable for runtime user sensitive interactions ;-\

[Danial Farid]

@cd: IMO css styles, layouts classes, the order and methods for adding widgets to a page are all part of the view and dependent on each other, so it has its own drawbacks to assume that css is a totally different concern and people are always confused whether they should put their css styles in the code or in the .css file.

For example if you have styles like position:absolute or float it will totally change the layout of the page so the way you add you widget to your container and type of container you would use might need to be change depending on those styles.

In the last couple of jobs I had in agile environments, designers would just give you a mockup which would be merely an image of what the page should look like and the developer has to cut the colors and css rules to make the page look like that. So developer was responsible for maintaining the .css file, thus it would be more convenient to have style embedded in the code. In general there are many developers that are good with css and they don't need a designer to deal with the page, they might just need a designer for the logo and color of the page.

I've used it for my own project and it makes styles more maintainable. There is no need to jump to .css file all the time to search for the rule that is assigned to a widget. You can group styles together which makes the code much cleaner.

@Vitrums: 

That's a good approach, but you won't be able to change the theme dynamically. I already have a @Condition tag in the code which can be used to implement your theme example.

@StyleDef
@Background(value = "#333", condition=@Condition(expression="MOONSKEY.equals(theme)"))
@Background(value = "#F0F", condition=@Condition(expression="SUNSHINE.equals(theme)"))
public @interface BodyBackground {}

@BodyBackground

protected Widget getLabel() {
  return label;
}

The condition can be an expression or based on useAgent, dir or locale. For example in my other project I needed to use different styles for RTL language support so the dir condition would come very handy. You can also use @GlobalCondition to reduce the code if you want to assign multiple styles for the same condition.

[Danial Farid]

@cd

One more thing: to change the styles without the need to recompile the code, I always use chrome or firefox inspector (right click on the element and click "inspect element"). You can modify the style and see how they look like right on the page and when you are happy with the changes, you can modify your annotations accordingly.

[Vitrums]

Each modern browser has its own DOM inspector. After a couple of tense non-stop coding month I've made a clue, that Opera-browser's got the most user-friendly debug tool among others. Sad to accept the fact it's got no GWT development plug-in. From the other hand web-kit based browsers are a lot faster, and it's a big part of a deal, when you debugging your app intensively. That is, the chromium one suffice the needs pretty close.

Concerting run-time scope annotations like the @Condition one, it's a sequential sacrifice of end-user processor resources upon the page-loading stage, since in a commonplace GWT best practice cases, this part of preprocessing lies upon the deferred-binding shoulders. But still, good job, since it's fair to mention, that far not all projects have a profit of cascading or MVP.