On Fri, Nov 21, 2008 at 1:37 PM, dflorey <[EMAIL PROTECTED]> wrote: > 1. The CssResources are very powerfull but why do I have to write > a .css file?
An early draft of CssResource with only class-based selectors used Java annotations as the basis for providing the content of the rule. It turned out to be very awkward in terms of manipulating the code (example below), since Java lacks multi-line string literals and you wouldn't get any help from your editor. Furthermore, there wasn't any obvious place to encode style data for things other than plain class selectors. While descendant selectors are to be avoided when you can do so, they do allow for loosely-coupled or composite widgets to be aware of "stateful" classes (such as .enabled or .focused). > This would enable gwt to grab all defined styles and create a minified > stylesheet per browser similar to the js output. How would the compiler know which stylesheets were part of the deployed app, and which stylesheets were unused parts of a library of things? > 2. Why and when do I have to inject the stylesheets? It's not very > clear when and why I have to take care of injecting stylesheets. I > guess that the styles are applied by using some runtime javascript > style injection (correct me if I'm wrong). The StyleInjector utility class will add a stylesheet to the page. Be aware that IE has a limit on the total number of dynamically-added stylesheets, so I'd recommend a pattern of StyleInjector.injectStylesheet(css1.getText() + css2.getText()); This will allow the compiler to perform string concatenation between modularized CSS files, assuming that you have exact knowledge of the widgets to be used in an application scenario. > I'd prefer if the generated minified browser specific stylesheets > would be injected automatically (or somehow included into the > embedding html page) CssResource doesn't generate CSS. It generates a Java expression that evaluates to CSS. It is generally the case that a non-trivial CssResource cannot be statically evaluated. The normal deferred-binding and dead-code rules apply, so the property-based @if rules will in fact result in browser-specific CSS. > 3. Do we need setPrimaryStyleName? I'd prefer every widget would take > optional WidgetResources as cstr. argument to customize its look > (including localized text etc.) The use of setPrimaryStyleName() can be obviated by the use of an injected resource bundle. > 4. Move Contants and Messages capabilities to ImmutableResourceBundle I can create a simple resource type that acts as a getter for Messages or Constants types. When ClientBundle is merged into trunk, it may be worthwhile to reconsider whether or not the I18N support can or should be subsumed into ClientBundle. > @CSSStyle(verticalAlign = VerticalAlign.MIDDLE, fontSize = "11px" ) This would require that the definition of the CSSStyle annotation have every valid CSS property encoded into it. This can be done, say for CSS2, but it would ignore the very useful browser-specific properties. An open-ended setup would require a key/value meta-annotation, thusly: @CssStyle(other = [EMAIL PROTECTED](key="-webkit-rounded-border", value="5px"), @KeyValue(key="something-else", value="foo")}) This is excessively verbose. > @CSSStyleIE(fontSize = "12px") A type per browser or value-of-deferred-binding-axis would be problematic if a given permutation matched multiple predicates. Declaration order matters in CSS; how would the system that you propose determine the final ordering of rules in the generated stylesheet? > To customize a widget you just have to subclass this interface and > override what you want to see changed. This is the case with the present implementation. The ImmutableResourceBundle / ClientBundle system does allow for extra resources to be plugged in without modifying the core code code-gen if you want to experiment with alternate ways of encoding the style data. Take a look at TextResource / TextResourceGenerator to get started. -- Bob Vawter Google Web Toolkit Team --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
