In all technologies building the equivalent using the approapriate native language is a pain, it takes a lot more lines to achieve the same thing. Conciseness is always a good thing. Any complex layout involving more than a few panels and widgets becomes hard to visualize when one stares at the code, but is infinitely more easy when one looks at the UIBinder equivalent. With the former one needs to execute the code in your mind just to try and imagine the result, because initially one has no idea where each widget and panel really is.
Using XML to declare UIs is quite popular these days: * XAML is the new way Microsoft has introduced for defining Silverlight and WPF applications. * Apple pioneered a similar approach a long time ago, where developers use a tool call Interface Builder to achieve similar objectives as uibinder. (the technology name escapes me). * Browsers. Technically not XML nevertheless it would be really hard if all pages were constructed from Dom manipulations without any first class support for HTML from browsers. All of these major vendors and systems would not have copied this idea if it had no merit. On Dec 13, 7:06 am, philippe <vonck...@yahoo.fr> wrote: > Using annotations to define the presentation is a bad practice, as > being able to define the size of components in Java. The best way to > separate the presentation logic is to give a class name to an element > and define its presentation in a separate CSS file. See csszengarden > as reference. > > Currently on the project I lead in GWT 1.7.0, I use a simple pattern > to separate "presentation" Java code from "logical" Java code. > > I don't think UiBinder be adapted to most projects. UiBinder is > probably useful in some specific cases, but not in most cases. May be > useful for managing complex components. I think in most cases, coded > as Swing is more appropriate. > > I think it would be interesting to propose a reference pattern for > developers to help them get a code of good quality. > > On 11 déc, 20:06, David Durham <david.durham...@gmail.com> wrote: > > > On Fri, Dec 11, 2009 at 6:23 AM, Stefan Bachert <stefanbach...@yahoo.de> > > wrote: > > > > The advantage of declarative programming could be reached in Java in a > > > much better way. > > > Look at the following code, it is pure Java and much more declarative > > > then UiBinder. > > > It has very less code and is in the end much more flexible since code > > > could add any rule you like. > > > > new DialogCreator() > > > .add(localization.account(), account, 100, DialogCreator.lines > > > (1)).newLine() > > > .add(localization.password(), password, 100, DialogCreator.lines > > > (1)).newLine() > > > .add(localization.session(), session, 100, DialogCreator.lines > > > (1)).newLine() > > > .button(ok) > > > .button(cancel) > > > > If you don't like parameters per position, ok, change it to: > > > > new DialogCreator() > > > .add(new DialogItem() > > > .label(localization.account()) > > > .item(account) > > > .width(100) > > > .height(DialogCreator.lines(1)) > > > ) > > > .newLine()..... > > > > What could be done in UiBuilder better/more readable than in java? > > > What are your thoughts? > > > > Stefan Bachert > > > > PS: It is like Spring. IoC could be done in Java itself. Why to deal > > > with this human unreadable XMLs? > > > a java compiler is much more flexible and exact as a validation of a > > > xml (try the check a mispelling of an java class!) > > > Another approach is annotations. You can see an approach like this in > > my little forms > > project,http://gxtforms.appspot.com/,http://gxtforms.googlecode.com/. Be > > sure to check out the source tabs > > at the bottom. I could see something like: > > > @Style(width=100, height ...) > > class MyDialog() { > > > } > > > or > > > class MyPanel() { > > > @Style(width=100, height ...) > > Dialog myDialog = new Dialog() > > > Just kind of thinking out loud here. > > > -Dave -- 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.
