Hi Sony,
I just wanted to clarify that UiBinder is based on XHTML not merely to make
coding more succinct vs. Java code. I agree that we could in theory provide
fluent APIs that could make Java imperative UI code much more succinct than
it is now. But there are three other big motivations for UiBinder that
wouldn't be address by fluent APIs that I wanted to share.

First, specifying layouts in XHTML encouages developers (by making it
easier) to use HTML rather than widgets/panels where the two are effectively
equivalent anyway. For example, it's just as easy to use "<div>" instead of
"<FlowPanel>" when you're already working in XHTML, yet <div> is much, much
better. Browsers can parse and render HTML string fragments much faster than
they can executing JavaScript that builds DOM structures programmatically.
So, really, UiBinder is a trojan horse to get people to write apps that are
smaller and run faster :-)

Secondly, many teams we've worked with at Google really like that UiBinder
creates a firm wall between the aesthetics of the UI vs. its programatic
behavior, which supports well the MVP pattern that is becoming increasingly
recognizes as The Right Way to architect internet-based client/server apps.
It's also a good way to divide work in teams that have designers and
developers; designers can mess with the XHTML, developers can mess with the
code and if they ever diverge, you'll get a compile-time error. This seems
to really facilitate the kind of workflow in which a lot of people have
expressed interest since GWT 1.0. We're excited to finally be getting there.

Finally, GWT is all about finding coding patterns with which tools (IDEs in
particular) are useful. UiBinder's XHTML syntax makes it easier to write
good tools because it isn't as expressive as full-blown code: more
restrictive language means more ability to analyze it statically, which is
what tools are all about. Fluent APIs that would encourage people to write
UIs with Java code are less amenable to creating good tools for them. For
example, the Google Plugin is already working on tools to make editing
UiBinder templates easy breezy, and we hope other IDEs will do the same.

-- Bruce

On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew <[email protected]> wrote:

>
> One point I have tried injecting into the GWT community is the
> importance of fluent APIs.  GWT's Java API is currently quite
> cumbersome for layouts and it seems folks immediately jumped to the
> conclusion that Java doesn't work and have gone the route of using XML
> for layouts.  I am not against folks that want XML layouts but there
> are many that feel fluent APIs in Java for layouts will be even more
> productive  Even if you layout your initial UI in XML you are still
> going to need to modify it dynamically in Java based on various events
> - so you end up having a eye sore mix.
>
> I put out an example of a fluent API called AxisPanel (search for it)
> - its not a great implementation - but it pretty much let me layout
> everything pretty quickly and changed the pace of my GWT development
> drastically - especially when it came to modifying layouts with new
> requirements.  Speaking for myself - I would like to see more such
> APIs (and better implementations than my AxisPanel) that folks can
> rely on as part of the Core GWT.
>
> I don't think developers starting a new GWT project would adopt XML
> layouts if they could fluently layout in Java right alongside the rest
> of their coding (at-least thats my theory)..
>
> Sony
>
> On Aug 10, 8:59 am, Arthur Kalmenson <[email protected]> wrote:
> > Hello everyone,
> >
> > We've been playing with UiBinder and I thought it'd be a good idea to
> > share what we've seen so far (and ask some questions).
> >
> > Some of the apps we write are used by more then one hospital and this
> > requires a tailored UI depending on the user's preferences and to
> > store additional information that a particular hospital needs to keep
> > track of. At the moment, writing UI in a swing style, we program to
> > interfaces and use GIN to bind everything together. Using different
> > AbstractGinModules and Ginjectors, we can tie the application together
> > in different ways using different UI implementations. What would be
> > the way to do this with UiBinder? From what we could tell, one would
> > use UiTemplate, but there doesn't seem to be a way to configure the
> > String in UiTemplate easily through a GIN module. Are there
> > alternatives?
> >
> > Following the programming to interfaces theme, we've been doing that
> > with UiBinder, but have run into an issue when trying to build a
> > larger UI page out of smaller ui.xml classes. It seems that referring
> > to interfaces in ui.xml doesn't work, so you need to work with direct
> > concrete classes. But this would force you to use a particular
> > implementation when we'd like to keep it generic.
> >
> > Lastly, I guess this is something just for consideration for the
> > future, but having the GEP work with UiBinder would make using it a
> > lot easier. For example, having code completion, refactoring support
> > and error messages right in Eclipse. This would be something like the
> > Spring IDE plugin that one you configure Spring XML files with all the
> > above features.
> >
> > Thanks again for the UiBinder, we'll definitely have to spend more time
> with it.
> >
> > Best regards,
> > --
> > Arthur Kalmenson
> >
>

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to