Hi Ed,
Regarding UI-Binder
The fact that others are using similar concepts like Ui-Binder does
not make it right. It just make it common.
(150 years ago woman suffrage was not common, but would you say it was
right what 150 years ago was common?)
What is wrong with UI-Binder?
a) it is an other XML-based language. XML is not really human
readable. It the end, you need a tool.
b) it is a further language. Everything you could do with it, could be
done with java, too.
You could write very declarative java code if you like. No need
for Ui-Binder
c) it is not expandable at the moment. Try to add your own widgets.
d) It does not support theming. Changing a theme means recoding the UI-
binder
UI-Binder is a concept fitting rather to the mindset of a web designer
(this one graphical beautyful application (NO plural!)) than to a web
developer (deliver functional, supportable applications).
"Being fast"
Most companies suffers on the long run from doing things quickly but
not right. These companies will pay the price in future.
Because they are unable to change their theme or skin.
"Single point of control"
I want to be able to change all my widgets used in an application at a
single place.
And it should be regardless whether this widget comes from gwt core,
widget library a or widget library b or from me or my colleague.
Style modules
To exchange a style module it must be separated. that is the
consequence of your reduced requirements.
So each of your reusable widgets need an own style module. It has to
be duplicated for each theme.
When you are having 30 widgets used in 5 applications with different
styles (aka theme/skin) you need 150 style modules.
With a1decor you need 5 different implementations of a theme.
It is alway surprising that a more complete solution do reduce the
effort
Definition of a theme in the sense of a1decor:
A consistent graphical representation of widgets and symbols.
layout is not considered to be an issue of a theme in this sense.
CSS
CSS was advocated by separating structure from style. This is a
variant of "separation of concerns".
However, within a CSS there is NO possibility to separate further
concerns.
With CSS I see at least to following concerns "within"
a) layout/visibility should not placed in .css-file at all.
b) theming attributes (borders, colors)
c) functionality attributes. (e.g pointer kinds)
a) is separated because it applies from code not from css-file. This
is rather an accident than designed.
Often we just have luck because different concerns affect different
style-attributes. But this is not guarantied
When b) and c) want to affect the same css-attribute (let's say
padding) there is no way to express it.
a concrete example is "pressing a button":
from functionality point of view you want different paddings when
pressed and when not pressed, to make them look like pushed in.
from theming point of view you want to apply a certain padding
(compact versus broad).
However, in the end you need to apply a single value to the padding-
attribute. There is no way to express that padding is defined by TWO
concerns, not even how they apply (add, min, max ..).
"The lesson learned" is:
pure declarative systems are going to fail when trying to increasing
the degree of separation.
You need some kind of procedural language to separate concerns, or
better to consolidate multiple concerns to one value.
Due to this "lesson learned" Ui-Binder will fail in large
applications, too (due to: pure declarative without procedural
language).
I definitely will not wait until this happens. I am using Ui-Binder
just for quick and dirty toys, and may be for some test cases.
For a consistent gui all widgets must share similar attributes. Your
questions sounds as this is no issue for you. One widget look compact,
the other looks broad?
Anyway, when you do adapt a consistent theme to all your widgets you
need to change many styles. This is a lot of work and is in general
not done.
Or you have a single point of control
It is right that the current way implies more freedom than with
a1decor, but when this implies an enormous amount of effort you will
never use your freedom. So what did you win?
(did you know the joke: Marketing; We want to deliver the most
adaptable flexible program: Development: OK, guys, tomorrow we deliver
Java or C++ to our customers)
regarding the large @def section:
It may be annoying because it is just convention not programming.
However, two things may happen
a) you just need a subset for a specific widget
b) maybe some one do an special CssResource-Generator were all that
conventional stuff is implied.
I am going to start on that. It addresses the problem which is far
from generally understood, and maybe someone comes up with an great
idea to make it easier.
I do not fear this because the most work is defining the css and a
better solution will probably only reduce to conventions part while
still using the css.
Stefan Bachert
http://gwtworld.de
On May 1, 11:00 pm, Ed <[email protected]> wrote:
> 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 <[email protected]> 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 [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > 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 [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> 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 [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.
