And Stefan answered this back: Hi Stefan, > Looked at your project and played with it, but I don't think it's not solving > my problem and it's not the way I like to work with styles. > Why should I want to put my style value's in code like you do in your > DecorInterface?
Because you want to have a single point of control. And the other benefits documented on the project page of a1decor > I want them only in CSS files that come with a widget. That is a fault. When you bind a widget to a certain css no change is possible. But you want to have a change to chance. That's the nice thing about this CssResource concept, you can have one widget with one or more Css files, resulting in clear checked compact css files. > That is wanted, but in practice it does not always work. But this is an issue > for GWT > The idea is to be able to replace/inject another CSS file with the same > widget (injecting/using another Client bundle). I feel this jumps too short. In common you don't want to change the css of a single widget, you want to change the theme of a whole application. However, the technique you need for your reduced requirement is used in a1decor. You just do variants like a1decor-style do. You separate your CssResource in an own module. Each variant is just a duplicate of this module with modified values. You select the CssResource you need per class path, that is the trick. > GWT also advices to put all your Style value's in CSS files. I think the GWT doc really state this. Any way, this is oversimplified and therefore rather wrong. Positions should not be part of a css, for example. Exception are only valid on the absolute top level. >From the values within a css there are at least two sorts: a) one related with a theme b) one related with functionality The general problem with css is, that is does not really is able to separate concerns. This is funny because css was advocated with this argument. But css failed to fulfill this. You could not separate concerns when they affect to the same css-style (e.g. because a functionality and a theming aspect want to change "padding". But luck, either or, but no AND possible) > I expect that GWT will also make more use of the ClientBundle/CssResource > concept for their widgets in the up comming releases, > with the risk that your concept will lose his power. This may happen. When GWT solves my intended issues, it is absolutely fine. However, I do not expect it. GWT is absolutely outstanding regarding compiler technology, but rather mediocre on gui design and their concepts. The widgets are rather poor designed, MVP is middle- rated, UiBinder was a step back. So GWT needs support in this area and I am going to solve one issue after the other. a1decor was one little step, but a strategic one. > And when using your code, you might have to refactor a lot of code when > upgrading to a newer gwt release. I did not expect this. GWT needs to run "legacy" app, too. So GWT will not automatically bind CssResource to core widgets. Just wait a see. > Just my thoughts, but maybe I miss understand it.. > Anyway, back to my problems: like my original question: can you point out how > your code solves my problems listed above ? When you think, my answers are failing to explain that, please ask a concrete question. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
