Thanks Sefan, I agree with you on some of the issues you discuss, but not all of them. You are right that GWT's ClientBundle/CssResource concepts still have some issues, just like their widget design (some of my issues are in the issue tracker). But I don't think the UIBinder is a step back. Don't forget that many company's have to deliver fast and such work with GUI design tools like GWT Designer. UIBinder is the foundation for such tools. It's not for nothing that facelets became part of the JSF 2.0 spec and the Flex template mechanisme is the huge success behind Flex, all founded on the same concepts. Thet GWT dev team is just very careful and don't want to create a lock- in situation, so.. that is sometimes frustrating... but that's how it is and it probably takes a few releases ......
Anyway, some of my answers are inlined, looking forward to your answers. > Because you want to have a single point of control. What do you mean by this? Isn't that the whole idea of ClientBundle/ CssResource.... Even with his current problems/restrictions > 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. Why isn't this possible ?... Suppose a widget has his own css files, the developer can copy this and use it to inject his own css file through his own client bundle... at least... that is the "gwt way"... And you can always fine tune with dependent style names. > However, the technique you need for your reduced requirement is used > in a1decor. You just do variants like a1decor-style do. You separate > yourCssResourcein an own module. Each variant is just a duplicate of > this module with modified values. You select theCssResourceyou need > per class path, that is the trick. I can't really follow you here, can you give me a concrete example? I have dozens of reusable widgets, I hope I don't need to a style module for every one of them :(... > 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. What do you mean by this? How do you define you Theme then ? To me this sounds a bit too course grained and a different kind of problem... I simple want to be able to change my style values of one reusable (composite) widget. Do you mean that you define a theme as the collection of style definitions of the resusable widgets that you use in your app ?... This comes down to the same problem I think, as I don't want to change the Theme, as I only want to change one reusable widget.... Why should I need to change my Theme for this ? ... > 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).. Sorry, you are losing me here. Can you give a concrete example? > I did not expect this. GWT needs to run "legacy" app, too. So GWT will > not automatically bindCssResourceto core widgets. Just wait a see. Yep, I am also afraid of that, which is also what Thomas mentions above... I guess we will see major changes in this area in version 3.0... I like your idea's btw, but I am not very sure if it's very practical in larger app's and if it's the best solution in my case. If I look at my GWT app's, which are complex and have a total code base of about 2MB (downloaded in pieces).. I am a afraid it will become very messy if setup my css files like you propose... For example: if I look at my date picker styles, they will get very large with all the @def at's, not even to speak about all the code behind is. Of course the compiler will optimize a lot, but stilll.. it als has to be manageable. So I gain a lot of freedom and can override then every style value of my datepicker, but the question is: is this flexible worth the bunch of extra more-difficult maintainable code ? I don't know to honest... Ed On May 1, 10:23 pm, Ed <post2edb...@gmail.com> wrote: > 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 thisCssResourceconcept, 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 > yourCssResourcein an own module. Each variant is just a duplicate of > this module with modified values. You select theCssResourceyou 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/CssResourceconcept 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 bindCssResourceto 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 google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
