Hi, > * a further language. No way to debug it > FALSE: xml is not a new language, there is an XSD, there is also a eclipse > editor with auto complete and inline problem highlighting to work with your > own ui.xml template.
XML is rather structure of a language. When you consider this as a language, englisch, german, french, russian, italian needs to consider be the same language because the have the same structure. They do building words with characters from an alphabet. This is different from corean or chinese. > > * limited to a set of widgets > FALSE: the only requirement to attach a widget in a ui.xml is that it is a > widget. I checked this again and you are right. I missed that the namespace is assigned to a package. Probably comes from using the namespace for non widget (<g:north> for example) Beside, I still do not see, how own container analog to DockLayoutPanel can be setup. However, this is neither a focus of my generator approach. With this aspect my generator approach and UiBinder are nearly the same My generator approach is still a little bit better. Rename your widget in eclipse. Eclipse also change the class name in the definition interface, UiBinder produces errors. Or rename UiBinder.ui.xml, the class isn't renamed, producing errors. > > * it is a graphic designer mindset (we do this app, the app is our concern) > not a developer mindset (we do this class of apps, we separate concerns) > *TRUE: and this is actually a very good thing for several reasons.... This depends how many application you are going to do with GWT. When you are going to build multiple application, topics like reusability, consistency and separation of concerns become important. graphic design in general do not consider such aspects (there are exception from the rule) > * no clear separation, no SoC. A big bunch of widgets and css-styles. > *FALSE: You're java code does not contain layout or styling. There is SoC, > you can manipulate rebuild your look and feel, layout, style without > touching the java code. Separation of Look and Feel is just one level of SoC. And UiBuilder mixes up structure and layout. This is the opposite of SoC. To separate further is not possible, dead end as I have shown it. > > * no separation of theme/skin > *FALSE: you can switch the (ui.xml) template file a new UiBinder per theme? graphic designer mind set? This is a good as to write a new application per theme. Achieving reuse is a major goal for developers. >or CssResource several > ways, and you can always load @external styles in the css/ui.xml or > programatically set/implement them. Maybe you should explain this in a separate thread. To have a use case, please show how you would change color, font and padding at a central place outside UiBinder but with impact to UiBinder. > > Hope that's the factual information you were looking for :) Yes, there was some. But what about the following > > generator: layout automatically according css-style and annotations > > UiBinder: dialog designer does it manually. > > > generator: i18n constant change at any time > > UiBinder: i18n per compilation > > > generator: automatic labeling, yes > > UiBinder: automatic labeling, no > > > generator: consistent layout is automatically asured > > UiBinder: layout by accident/capability of the designer Stefan Bachert http://gwtworld.de > > On Wed, Jun 23, 2010 at 11:45 PM, Stefan Bachert > <stefanbach...@yahoo.de>wrote:> Hi, > > > On Jun 22, 3:36 pm, Andrew Hughes <ahhug...@gmail.com> wrote: > > > Almost all of the "problem's" listed below are bad advice and I suggest > > you > > > disregard them. > > > Do you, or others, have any valid arguments (opinions are no valid > > arguments) > > > I am not going to do things the wrong or the poor way just because > > most people are doing so. > > > > The main problem I have with UiBinder is that when you try and use it > > with > > > the MVP architecture "best practice", you have to boilerplate all the > > > parent/child (view) widget's. Which means you'll see a lot of..... > > > I am explaining the long story about my lessons I learned. > > > The problem with any pure declarative language is that you reached the > > dead end of separation. > > Either a dedicated aspect of separation is build in, or you are lost. > > There is always a tradeof where declarative languages will become more > > complex than an imperative one. > > > UiBuilder is a pure declarative language. > > > Let us look at CSS as a simple pure declarative language for example. > > Consider there are two aspects/concern defining an value. > > aspect 1) general theming. you want a certain padding > > aspect 2) behaviour, you want to simulate a pressed state. Therefore > > you need to change padding depending on the state > > > With a imperative language ("java") you would just combine/add both > > aspects. > > With a language like css either this is supported or not. In css it is > > not, bad luck. > > (CSS3 supports a little imperativity with calc, but only FF is > > supporting this somehow) > > > And the pure declarative language CSS 2.1 still fails to support some > > simpliest common needs. > > Remember all the time the topic of centering widget is coming up. > > > UiBinder fails the same way. It limits always your capabilities as a > > developer. Either a concept is explicitly supported, or you are lost. > > > There are other ways to be more declarative. One way is to use fluent > > interfaces. Than you use both declarative and imperative approaches, > > and can switched to the one which is more appropriate > > > the way I am currently using is to define interfaces and use > > generators. > > The input looks like the interfaces at the end of this mail. > > It defines a dialog with 2 subdialog. > > > To create you need just. > > LogonDialog logon = GWT.create(LogonDialog.class); > > .. > > logon.layout(); > > logon.setI18N (..Constants); > > > Accessing is a easy as > > String text = logon.eingabe.eMail().getText() > > > Let us compare this approach with UiBinder > > > generator: only one annotated interface for deferred binding > > UiBinder: class and UiBinder.XML with XMTL, CSS and WidgetsTags > > > generator: layout automatically according css-style and annotations > > UiBinder: dialog designer does it manually. > > > generator: i18n constant change at any time > > UiBinder: i18n per compilation > > > generator: automatic labeling, yes > > UiBinder: automatic labeling, no > > > generator: styles based theming > > UiBinder: styles based on accident > > > generator: widgets, any with a default constructor > > UiBinder: some widgets > > > generator: consistent layout is automatically asured > > UiBinder: layout by accident/capability of the designer > > > generator: debugging: yes, pure java > > UiBinder: no chance > > > Open questions with UiBinder > > * how to deal when the themes > > * how to use it a input for further code generation (I think no way) > > > Capabilities with generator approach > > * rules are in the generator, one place > > * control combined widgets (text + label for example making both > > enable/disable/hidden) > > * input is usable for further code generation > > Ideas > > * generate controller code, too (input DialogInterface and an > > interface defining a domain/app/session object) > > * generate request code, too > > * generate client cache code, too > > * ... > > > UiBinder is for the one how like to stay in a death end. > > > When you want to generate boiler plate code, > > you need to get rid of UiBinder. > > > Stefan Bachert > >http://gwtworld.de > > > ----------------------------------------------------------------- > > @SpaceStyle("a1-DialogSpace") > > public interface LogonDialog extends DialogInterface { > > > �...@onlyi18n > > static interface Eingabe extends DialogInterface { > > > �...@label("eMail") > > �...@newline() > > public TextBox eMail (); > > > �...@label("kennwort") > > �...@newline() > > public PasswordTextBox kennwort (); > > > �...@label("kennwortWiederholung") > > �...@newline() > > public PasswordTextBox kennwortWiederholung (); > > > public void setI18N (Lokalisierung pI18N); > > } > > > �...@onlyi18n > > �...@spacestyle("a1-ButtonSpace") > > static interface Schaltflaeche extends DialogInterface { > > > �...@text("anmelden") > > �...@newline(LineBreak.BREAKEND) > > public Button anmelden (); > > > �...@text("kennwortVergessen") > > �...@newline(LineBreak.BREAKEND) > > public Button kennwortVergessen (); > > > �...@text("registrieren") > > �...@newline(LineBreak.BREAKEND) > > public Button registrieren (); > > > public void setI18N (Lokalisierung pI18N); > > } > > > �...@placement(horizontal=Alignment.GROW) > > public Eingabe eingabe (); > > > �...@newline (LineBreak.BREAKEND) > > public Schaltflaeche schaltflaechen (); > > > �...@placement(horizontal=Alignment.GROW) > > �...@height (3) > > �...@newline (LineBreak.BREAKEND) > > public HTML meldung (); > > > �...@width (-400) > > �...@placement(horizontal=Alignment.GROW) > > public HTML hinweise (); > > > public void setI18N (Lokalisierung pI18N); > > } > > > -- > > 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<google-web-toolkit%2bunsubscr...@googlegroups.com> > > . > > For more options, visit this group at > >http://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.
