On Tuesday, February 18, 2014 6:38:36 PM UTC+1, GWTter wrote:
>
> Hi all,
>
> Let me just go with an example right off the bat.
>
> Let's say I have the following:
>
> === Pseudocode ===
>
> SuperCssResource: This is injected onModuleLoad before anything else
> .genButton{
> color: black;
> }
>
> Widget1 consists of:
> --- css ---
> MyCssResource:
> .myButton{
> color: red;
> }
>
> --- html ---
> <button class="genButton myButton" />
>
> Widget2 consists of:
> --- css ---
> XCssResource extends SuperCssResource:
> ... rules that use classes from SuperCssResource
>
> --- html ---
> ...elements
>
> My problem is that if I display Widget1 first and then display Widget2
> then the button in Widget1 will have a color of black instead of red.
>
> I know that this is expected behavior (GWT will merge the stylesheets
> together) since inheritance is basically the cssresource equivalent of CSS
> @import <http://www.w3.org/TR/css3-cascade/#at-import>
>
Er, no.
Inheritance of CssResource interfaces only deals with that: inheriting
methods. The actual CSS backing the resource is given by the @Source
annotation on your ClientBundle method, and if you use the same CSS file
for 2 different CssResource interfaces, the CSS will be duplicated, because
obfuscation of the class names is based on the interface fully-qualified
name:
http://www.gwtproject.org/doc/latest/DevGuideClientBundle.html#Scope (the
order of the files in @Source will impact merging, just as they'd impact
precedence in CSS).
> but I thought since this was GWT maybe there was a way to use inheritance
> in the sense that the inherited stylesheet would only be injected if
> not injected already. Is this currently possible? or could it be done with
> like a @Require annotation on the extending interface which would indicate
> that merging of the super stylesheet should not be done but rather a check
> would be made to see if it already exists and if not to inject it.
> This would easily resolve the specificity overriding issue in the example
> when it's not the desired behavior.
>
> I know I could also get around this by importing with a prefix, however I
> still don't like the idea of essentially reinjecting the same styles.
>
If you don't want duplication, then you need a "shared scope" or "imported
scope". In any case, that means you should only use the shared/imported
class names in more complex selectors, you shouldn't change the styles
attached to the selector by itself.
None of this applies if you use "@external" though, then it just works like
standard CSS.
…and no, there's no way to say "please make sure that other stylesheet is
injected when injecting that one", because, to begin with, it'd be hard to
define what "that other stylesheet" is (the interface is not enough, given
that the @Source is set on the ClientBundle method, so you'd have to say
"this method from this ClientBundle interface", but it wouldn't even be
enough: what if you composed that interface with another one and
GWT.create()d the composed interface? should that @Require mean that GWT
would do a GWT.create() of the lone interface, therefore duplicating
efforts? –in all honesty, I haven't looked closely at the impact in terms
of generated code and how it could be optimized, but it could limit future
evolutions of ClientBundle in which code it generates, just to make sure
that feature would still be correctly optimized–)
No really, given that ensureInjected() is a no-op if already injected, just
make sure you call ensureInjected() on your "required" CssResource before
calling ensureInjected() on the one that requires it, and document it
thoroughly in the javadoc of the requiring ClientBundle method.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
