There are a number of different tricks you can use for dynamic styling.
Because the StyleInjector is going to append to the head section, any style tags it injects will come after any existing content. One simple way to get your styles to override later appearing ones is to give the body tag an id, and then include that id in your rules. The resulting rule will have higher priority/precedence. Like: body#myid .gwt-Label { ... }
You can use RequestBuilder to retrieve the CSS file via Ajax, then inject the resulting string using the StyleInjector.
If your changes are just things like colors and background-image urls, and there aren't too many, you can write a class with static get methods to retrieve various values, like a color or url string. Populate the static fields backing those methods before injecting your CSS resource, and use things like @eval in the resource to retrieve the values within a rule.
If you actually want to replace CSS at runtime - to reskin for some reason, the only way I can think of to do that would be to manually create your own style element, and set it's inner HTML to the contents of an Ajax-retrieved CSS file. To change the styling, retrieve the alternate CSS file, and overwrite the contents of your style tag. (I suppose it could be populated in the initial HTML, but given an id so you can access it later to replace the rules.)
On Saturday, November 9, 2013 2:27:03 AM UTC-5, Aleks wrote:
-- Because the StyleInjector is going to append to the head section, any style tags it injects will come after any existing content. One simple way to get your styles to override later appearing ones is to give the body tag an id, and then include that id in your rules. The resulting rule will have higher priority/precedence. Like: body#myid .gwt-Label { ... }
You can use RequestBuilder to retrieve the CSS file via Ajax, then inject the resulting string using the StyleInjector.
If your changes are just things like colors and background-image urls, and there aren't too many, you can write a class with static get methods to retrieve various values, like a color or url string. Populate the static fields backing those methods before injecting your CSS resource, and use things like @eval in the resource to retrieve the values within a rule.
If you actually want to replace CSS at runtime - to reskin for some reason, the only way I can think of to do that would be to manually create your own style element, and set it's inner HTML to the contents of an Ajax-retrieved CSS file. To change the styling, retrieve the alternate CSS file, and overwrite the contents of your style tag. (I suppose it could be populated in the initial HTML, but given an id so you can access it later to replace the rules.)
On Saturday, November 9, 2013 2:27:03 AM UTC-5, Aleks wrote:
Hi all,
My problem is related to this blog post - http://googlewebtoolkit.blogspot.com.au/2011/03/ .styling-and-skinning-your- apps-with.html
Namely, I have a gwt app, using UIBinder that I wish to be able to style without recompiling. I have a 'default' style that is defined in a css in the src packages and included in all the *.ui.xml templates via the <ui:style src="..."/> tag.
Now I wish to be able to change the default style at runtime, but without recompiling. The link above suggests this is possible, and my understanding is also that they have default styles in the ui.xml files and then they override it in the static stylesheet included by the host html.
I've tried this, deployed my app (in dev mode) with the following organisation:
- the uibinder templates all reference a css file in a src package via the <ui:style src="..."/> tag
- now my host.html also <link>'s a different css where I use the same selectors with different values to override the style.
This does NOT work! The externally linked css seems to have no effect. Looking at the generated html, I can see the styles from the src package being obfuscated, but the linked css (when I click on the link) is as normal - no obfuscation. I am guessing that is part of the problem since the generated html elements definitely reference the obfuscated selector names.
Any ideas/hints on how to get this work or where I am going wrong?
Thanks!
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment