Hi, You don;t need to use just one CssResource. I use one per widget type. This makes it really easy to restyle and to manage. I also make sure that my custom widgets allow for a CssResource or even a ClientBundle as parameter so that you can define your own styles.
What I do not like right now about CssResources is that you need to maintain the .css file separately. Why not use some similar trick as used in JSNI code, allow us to inline the actual style. Also when I want to share colors and other constants between widgets it is also a bit more difficult and I end up exposing those internals to the CssResource since I need to subclass a base css that contains the generics AND I must make sure that I also point to the base.css file through annotations. Inheritance is tricky as well, it would have made more sense to me that we could override css attributes though CssResource inheritance and not through the standards CSS cascade. For example I could have a base button.css where I set something like background-color:blue and then subclass and redeclare the background-color:green. This does not work, so now I have to use yet another css file where everything except the background-color is set and then put the color specific in another css file and make sure that I put both in the @Source annotation. I know it makes sense in CSS but in OO it does not make sense - if you subclass a CssResource you expect the inhertiance on styles to happen the same way. David On Thu, May 16, 2013 at 10:44 AM, Spear Timothy <[email protected]> wrote: > Inline style in each UiBinder xml file will not be maintainable. > From a code maintenance perspective stylesheets should be used extensively. > > The suggested solution for this is to include the css as part of the > ClientBundle as a resource. > This suggested solution is predicated on the following assumptions: > -- a single CSS file (yes you can have multiple files, but this is MX > nightmare. Which variable..... > -- User does not have the ability to change/select alternate CSS files > -- Prevents the application from being re-labeled by an OEM SaaS unless > you also provide source code > -- Now you have to maintain and keep in sync three separate items. Class > name in CSS, Variable Names in CssResource file, declarations in UiBinder > XML File > > Now explain all the linkages to a junior developer who needs to change one > minor thing in a complex app. > > Tim > > On May 16, 2013, at 4:35 AM, Jens wrote: > > > Hm a bit more details would be nice. What is complicated on using > > ClientBundle? What code does it replicate? > > > > Whats wrong with: > > > > ExampleWidget.gwt.xml: > > > > <ui:with field="common" > type="my.app.client.resources.CommonClientBundle"/> > > > > <ui:style> > > /* specific rules for ExampleWidget, could also be externalized into a > > separate css file */ > > > > .myWidget { > > padding:5px; > > } > > > > .content { > > background-color:grey; > > margin-left:5px; > > } > > </ui:style> > > > > <g:HTMLPanel addStyleNames="{style.myWidget}"> > > <g:Image resource="{common.addIcon}"></g:Image> > > <div class="{style.content}"> > > I am some <a href="#">content</a> > > </div> > > </g:HTMLPanel> > > > > > > If you tell your junior developers "Put widget specific css into an > inline > > style (or widget specific css file) and take common things from the > common > > ClientBundle" whats hard to explain then? Also overriding CSS style on > > general HTML elements inside an UiBinder widget should pretty much always > > happen in the context of that widget so you dont mess up anything else: > > > > <ui:style> > > /* bad as it can globally override existing "a" CSS rules */ > > a:link { > > color:red; > > } > > > > /* better */ > > .myWidget a:link { > > color:red; > > } > > </ui:style> > > > > > > -- J. > > > > -- > > 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?hl=en. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
