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
-~--~~~~--~~--~--~---
