UiBinder first impressions

[Arthur Kalmenson]

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

[Miguel Méndez]

We have started looking at how the GPE could support UiBinder.  Of course, validation with markers and quick fixes, refactoring, etc are all part of it.

 

Thanks again for the UiBinder, we'll definitely have to spend more time with it.

Best regards,
--
Arthur Kalmenson

--
Miguel

[Gary Miller]

I'd like to start off by saying a big THANKS.
We've been hanging out for this, and it is making a great first
impression.

In regards to GEP, validation, code completion etc. Would it be
possible to use a xml schema per name space?
My XSD skills aren't to the point where I would know if this is even
viable.
If this is a Buddha nature question, then please let me unask it.

Could the need to custom parsers be solved by the same mechanism as
the GEP support?
Again with some meta data for widgets or widget packages.
e.g. XSD per package or an UiBinder Widget Annotations.

Are more custom parsers being written for the GWT UI components?
Or is this the set until the public parsing interface is nailed down?
As an example
I tried to use visibleItemCount on ListBox go an exception
"class ListBox has no appropriate setVisibleItemCount() method."
This is easy enough to work around by place the setVisibleItemCount
all in the java code.

Would it make any sense for @UiField to be applied to a setter/getter
method.
It might then be possible to code an interface that is bound to the ui
and allow different implementions. e.g. a common dialog interface.

Regards
Gary Miller

On Aug 11, 12:08 am, Miguel Méndez <mmen...@google.com> wrote:

[Jason Parekh]

Hey Gary,

I can't speak more generally about GWT, but can give you some info on the plugin.

We'll need more than just an XML schema (though we'll still have a simple schema defining the legal top-level elements, for example).  The autocomplete choices will be too dynamic to be included in a schema.  For example, when opening a tag, we'll offer autocomplete choices for each UiBinder widget in your code base.  We could generate an XSD from this information, but it may not be worthwhile adding that extra step.

Thanks,

jason

[Gary Miller]

Sounds great.

Is there enough information in the classes for new GEP functionality
or is extra information in going to need to be provided. Eg. the
capabilities of the com.google.gwt.uibinder.parsers classes.
There might be an opportunity to solve the custom widget parsing issue
and the GEP auto complete etc. with the introduction of widget
annotations.

Thanks
Gary

[SonyMathew]

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

[Bruce Johnson]

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

[Miroslav Pokorny]

Extras...

Are there any plans to build a ui tool (maybe in swing) so designers can drag n drop available widgets and have the view instantly updated?

 
Other kool features might include save the file etc.

Some of the extra features in interface builder.

Thoughts...?

[Bruce Johnson]

No plans to do drag-n-drop or anything wysiwyg. We'll probably
continue to focus on the basics.

On Tuesday, August 25, 2009, Miroslav Pokorny

<miroslav...@gmail.com> wrote:
> Extras...
> Are there any plans to build a ui tool (maybe in swing) so designers can drag n drop available widgets and have the view instantly updated?

> Other kool features might include save the file etc.Some of the extra features in interface builder.

[Konstantin.Scheglov]

> 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.

Will Google Plugin provide text editor for *.ui.xml files?
Is there any place where I can ask to make this editor embeddable
into MultiPageEditorPart?
This would allow us to compose corresponding Java, ui.xml and
WYSIWYG Design pages into single editor.
For example Eclipse Java editor can not be embedded, because there
are several dependencies in it and its actions, so we have to inherit
from it to add Design and other pages in WindowBuilder. But if Google
Plugin editor also will have such limitation, we will not able to
include it in same way.

I use MultiPageEditorPart just as example, most probably we will use
our own multi-page editor implementation (inherited from Java editor).

[Richard Vowles]

One of the things I have noticed with the UIBinder is that you can't
set the id on the fields - which is pretty important for css styling
and testing. I seem to have to set them in code.

<g:TextBox ui:field="tbWhatever" id="some-name"/>

causes it to fail to compile. I know id is an attribute of getElement
() but since this is a very common thing to do, I'd have expected
ui:id or some such (or just id being acceptable). Am I missing
something?

Ta
Richard

[Joel Webber]

The biggest problem here is that ids have to be unique within a document, and UiBinder has no way of enforcing this.

If you want to use it for styling, you're probably better off with CssResource (we're working on updating the samples to reflect what we believe to be the best pattern for doing this).

As for testing, I assume you mean using something like Selenium. This is actually why we created the UIObject.ensureDebugId() stuff -- especially so that you can turn it off in deployment. But if you're using GWTTestCase, you can just bind the elements to fields and grab those directly.

Cheers,

joel.

[Ray Ryan]

And you can set the debug id via ui.xml:

<gwt:Label debugId='joe'>Hiya, pal.</gwt:Label>

If you're not going to use CssResource, there is nothing you can do with an id selector that you can't do with a class selector. I really discourage the use of id selectors, they're brittle.

rjrjr

[Jason Parekh]

On Wed, Aug 26, 2009 at 5:21 AM, Konstantin.Scheglov <konstanti...@gmail.com> wrote:

> 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.

 Will Google Plugin provide text editor for *.ui.xml files?
 Is there any place where I can ask to make this editor embeddable
into MultiPageEditorPart?
 This would allow us to compose corresponding Java, ui.xml and
WYSIWYG Design pages into single editor.
 For example Eclipse Java editor can not be embedded, because there
are several dependencies in it and its actions, so we have to inherit
from it to add Design and other pages in WindowBuilder. But if Google
Plugin editor also will have such limitation, we will not able to
include it in same way.

 I use MultiPageEditorPart just as example, most probably we will use
our own multi-page editor implementation (inherited from Java editor).

Hi Konstantin,

That sounds great!  We'll definitely keep this in mind while developing UI Binder support in our plugin.

The current plan is to hook into SSE extension points for the XML editor.  We haven't yet had a need to create our own XML editor, but if this changes, we'll definitely aim to keep it embeddable in e.g. MultiPageEditorParts.

If you don't mind, could you file this as a feature request in the GWT issue tracker?

Thanks,

jason

[Konstantin.Scheglov]

> >   Will Google Plugin provide text editor for *.ui.xml files?
> >  Is there any place where I can ask to make this editor embeddable
> > into MultiPageEditorPart?
> >  This would allow us to compose corresponding Java, ui.xml and
> > WYSIWYG Design pages into single editor.
> >  For example Eclipse Java editor can not be embedded, because there
> > are several dependencies in it and its actions, so we have to inherit
> > from it to add Design and other pages in WindowBuilder. But if Google
> > Plugin editor also will have such limitation, we will not able to
> > include it in same way.
>
> >  I use MultiPageEditorPart just as example, most probably we will use
> > our own multi-page editor implementation (inherited from Java editor).
>
> Hi Konstantin,
> That sounds great!  We'll definitely keep this in mind while developing UI
> Binder support in our plugin.
>
> The current plan is to hook into SSE extension points for the XML editor.
>  We haven't yet had a need to create our own XML editor, but if this
> changes, we'll definitely aim to keep it embeddable in e.g.
> MultiPageEditorParts.

Thank you.

> If you don't mind, could you file this as a feature request in the GWT issue
> tracker?

Done.
http://code.google.com/p/google-web-toolkit/issues/detail?id=3986

[Amir Kashani]

While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, 

  <gwt:Button res:addStyleNames="css.myCssClass" />

doesn't seem to work. 

- Amir

[Ray Ryan]

It works. What does your xmlns line look like?

BTW, this is about to change. I'm implementing the expression language stuff mentioned in the wiki entry (http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder). So that line will become something like:

<gwt:Button addStyleNames="res.css.myCssClass" />

rjrjr

[Amir Kashani]

Hmm, I don't have it handy but it's the name xmlns I use for all other resource "injection", and those work fine. I'll give it another shot later today. I'm sure you're right and I just messed something up.

+1 for the expression language. Will res be required to be a subclass of one of the resource types, or will it work for any class? If the latter, it's a first step towards basic data-access from the template, which would be nice. 

- Amir

[Ray Ryan]

On Wed, Aug 26, 2009 at 5:23 PM, Amir Kashani <amirk...@gmail.com> wrote:

Hmm, I don't have it handy but it's the name xmlns I use for all other resource "injection", and those work fine. I'll give it another shot later today. I'm sure you're right and I just messed something up.

+1 for the expression language. Will res be required to be a subclass of one of the resource types, or will it work for any class? If the latter, it's a first step towards basic data-access from the template, which would be nice. 

The existing res stuff is already type agnostic, so we've already taken that first step--just nobody noticed. The change will be purely a syntactic one.

[Amir Kashani]

Oh, carry on then. Good show!

- Amir

[Richard Vowles]

I wouldn't mind some convincing urls to backup this viewpoint if you
have any :-) The entire rest of the team here is saying "id id id",
"class bad, id good". Searching for "html id brittle" wasn't very
enlightening :-)

I have also found that there seems to be no way of overriding the
class that is created when hitting HTML elements - it is hard coded in
UiBinderWriter to look only in the Google classes for elements with
TAG. Descending and fixing it for UiBinderWriter was relatively
straight forward (even tho I had to put the replacement class in
com.google...), but because all of the important methods are private
in UiBinderGenerator, I had to replace that and copy the methods,
which was triple yuk. Good to have the source though :-)

Solving the problem would be easy (i.e. allowing people to override
and replace their own classes only if they wanted to) by the
UiBinderGenerator asking for the UiBinderWriter through the GWT.create
mechanism and the right methods being protected in the Writer instead
of package private... You guys may already have a different solution
so it that is more elegant though.

Ta
Richard

On Aug 27, 3:56 am, Ray Ryan <rj...@google.com> wrote:
> And you can set the debug id via ui.xml:
> <gwt:Label debugId='joe'>Hiya, pal.</gwt:Label>
>
> If you're not going to use CssResource, there is nothing you can do with an
> id selector that you can't do with a class selector. I really discourage the
> use of id selectors, they're brittle.
>
> rjrjr
>
> On Wed, Aug 26, 2009 at 11:53 AM, Joel Webber <j...@google.com> wrote:
> > The biggest problem here is that ids have to be unique within a document,
> > and UiBinder has no way of enforcing this.
> > If you want to use it for styling, you're probably better off with
> > CssResource (we're working on updating the samples to reflect what we
> > believe to be the best pattern for doing this).
>
> > As for testing, I assume you mean using something like Selenium. This is
> > actually why we created the UIObject.ensureDebugId() stuff -- especially so
> > that you can turn it off in deployment. But if you're using GWTTestCase, you
> > can just bind the elements to fields and grab those directly.
>
> > Cheers,
> > joel.
>

> > On Tue, Aug 25, 2009 at 10:38 PM, Richard Vowles <richard.vow...@gmail.com

[Joel Webber]

On Thu, Aug 27, 2009 at 5:29 AM, Richard Vowles <richard...@gmail.com> wrote:

I wouldn't mind some convincing urls to backup this viewpoint if you
have any :-) The entire rest of the team here is saying "id id id",
"class bad, id good". Searching for "html id brittle" wasn't very
enlightening :-)

It's fairly easy to arrive at this conclusion from first principles. Element ids *must* be unique within a document. The fact that getElementById() can only return a single element makes this pretty clear and unavoidable (whether or not it was a good idea in [HT X]ML is another question altogether).

If you have a .ui.xml with an id in it, you can *never* use more than one in an app at the same time. While there are sometimes cases where one is pretty sure this constraint will be satisfied, there's no way for UiBinder to know this.

It also turns out that .class selectors aren't particularly different in performance from #id selectors. *descendant* selectors are pure evil, because they create an oft-unoptimizable case for the selector engine, but that's not what we're talking about here. So absent compelling evidence that .class selectors are problematic, I would say the onus is on the "id id id" team to make their case :)

I have also found that there seems to be no way of overriding the
class that is created when hitting HTML elements - it is hard coded in
UiBinderWriter to look only in the Google classes for elements with
TAG. Descending and fixing it for UiBinderWriter was relatively
straight forward (even tho I had to put the replacement class in
com.google...), but because all of the important methods are private
in UiBinderGenerator, I had to replace that and copy the methods,
which was triple yuk. Good to have the source though :-)

I'm not entirely certain I understand the problem here -- is the issue that you want to use an element for which there's no Element subtype in the .dom package? We didn't go to great lengths to make this extensible, because the set of legal HTML DOM elements changes at a glacial pace. But if there's one we missed, please let us know!

Cheers,

joel.

[Ray Ryan]

It's a fair point though, now that HTMLPanel allows you to set override its preferred "div" tag with any old thing. The lack of parallelism there is pretty arbitrary. Richard, would you mind filling a ticket on that issue?

[Richard Vowles]

No - more like (for example), when it hits a <label> it always creates
a Google LabelElement - say I want to create a MyLabelElement instead
(which does some extra thing, which in my case it does). I can't do it
without hacking it (which I have done). Happy to file an Issue on
this...

[Joel Webber]

It may not be a perfect solution to what you want to do, but because those are native DOM Elements, which subtype JavaScriptObject, you can cast them to any other JSO subtype you like. For example:

@UiField Element elem;

MyWidget() {

  // ...

  // If your element subclasses Element:

  ((MyLabelElement)elem).goCrazy();

  // If not, then:

  MyLabelElement lbl = elem.cast();

  lbl.goCrazy();

}

IOW, the generated code doesn't "create" an element, it just wraps the native element in a particular JSO interface, which you're free to change later.

[Ray Ryan]

Also, have you noticed the @UiField(provided=true) and @UiFactory annotations? They allow you to take charge of factory duties, instead of relying on the default GWT.create() behavior.

[Amir Kashani]

Ray,

I take it back, it doesn't work. Not for me anyway:

<gwt:UiBinder ... 

   xmlns:res='urn:with:my.package.Bundle'>

...

<gwt:Button res:addStyleNames="formCss.error" />

Results in

[ERROR] In <gwt:Button res:addStyleNames='formCss.error'>, class Button has no appropriate setAddStyleNames() method   

If I remove the res prefix, it works as expected. FWIW, I use res all over the template without any issues.

I haven't tried the new syntax to see if it works any differently.

- Amir

On Wed, Aug 26, 2009 at 12:22 PM, Ray Ryan <rj...@google.com> wrote:

[Ray Ryan]

I think you've found a bug with addStyleNames, which gets special handling. Do you mind filing an issue? 

The new syntax hasn't been committed yet, it's in review. Although now that I think about it, it just might accidentally fix this problem. Which is nice.

[Amir Kashani]

Accidental bug fixes are always welcome!

Issue 3994

- Amir

[SonyMathew]

Hi Bruce,

The goals you stated have been long sought by developers everywhere
(including me) and I hope you guys achieve it. In fact our last-gen
web tool/framework choice was based on this principle of roles
separation - but in all my years I have just never seen this work
(yet) - I am curious to know if your team or anyone has effectively
achieved this.

We finally rested on the following separation - allow UI designers to
use their favorite tool (e.g. Dreamweaver) to create full-fledged
mockups, then let the developers work off those to recreate the UI.
Attempting to share the underlying artifacts just lead to a lot of
complexity especially with several cycles of modifications - and -
both sides had to settle for tools & syntax neither were comfortable
with. Now with GWT - the UI designers use their tools and syntax and
the developers use their IDE and Java.

Now within developers, further role separation occurs between the UI
coders and the Service coders and so on (perhaps this is the
separation you were referring to) - but this is transitional at best
(as they switch around) - we do this now - some work on Panels (views)
exclusively for a while and so on. Even here separation using XML
likely means the same last-gen dev style - such as expression bindings
to Java variables and pretty soon Loop / If-then-else (and other
language constructs) in your XML to accommodate the dynamic behavior
expected from a view. The UI developer is restricted by XML rather
than having the full flexibility of OO at their finger-tips.

Regarding tooling:
Java can be statically analyzed - an IDE is the best example of a tool
that can analyze it.

Regarding performance:
The GWT compiler analyzes Java for optimization now - you could
provide APIs like panel.freeze() to allow static pre-generation of
HTML of frozen Panels (just throwing out ideas - not thought out
yet)..

An example of using a Table with Java rich goodness using Fluent
APIs...

public class DrugPricePanel extends SimplePanel {

public DrugPricePanel() {

AxisTable table = new AxisTable()

//main header
.nextRow()
.place("DrugPrices: An AxisTable Demo:
buildRowByRowPlaceDirectDemo")

//drug & costs header
.nextRow()
.place("Drug Name") //place content directly
into cell.
.place("--")
.place("Specialty")
.place("90 Day Mail")
.place("90 Day Retail")
.place("30 Day Retail")

//drug info + total costs
.nextRow()
.y() //Nest an
AxisPanel as cell content
.x(widgets.drugName).q() //(see AxisPanel info -
layout in x or y axis).
.x(widgets.drugDesc1).q()
.x(widgets.drugDesc2).q()
.q()
.place("Total Costs")
.place(widgets.drugTotalCosts.specialtyCost)
.place(widgets.drugTotalCosts.ninetyDayMail)
.place(widgets.drugTotalCosts.ninetyDayRetail)
.place(widgets.drugTotalCosts.thirtyDayRetail)

//your costs
.nextRow()
.place("Your Costs")
.place(widgets.drugYourCosts.specialtyCost)
.place(widgets.drugYourCosts.ninetyDayMail)
.place(widgets.drugYourCosts.ninetyDayRetail)
.place(widgets.drugYourCosts.thirtyDayRetail)


//main header //span across all columns
.cell(0,0).span(1,7)

//drug header //span 2 columns
.cell(1,0).span(1,2)

//drug info //span 3 rows and 2 columns.
.cell(2,0).span(3,2)

;//end-table

this.setWidget(table);
}

class DrugCostWidgets {
Label specialtyCost = new Label();
Label ninetyDayMailCost = new Label();
Label ninetyDayRetailCost = new Label();
Label thirtyDayRetailCost = new Label();
}

class Widgets {
Label drugName = new Label();
Label drugDesc1 = new Label();
Label drugDesc2 = new Label();
DrugCostWidgets drugTotalCosts = new DrugCostWidgets();
DrugCostWidgets drugYourCosts = new DrugCostWidgets();
}

private Widgets widgets = new Widgets();

}//end-class

[SonyMathew]

Hi Bruce,

The goals you stated have been long sought by developers everywhere
(including me) and I hope you guys achieve it. In fact our last-gen
web tool/framework choice was based on this principle of roles
separation - but in all my years I have just never seen this work
(yet) - I am curious to know if your team or anyone has effectively
achieved this.

We finally rested on the following separation - allow UI designers to
use their favorite tool (e.g. Dreamweaver) to create full-fledged
mockups, then let the developers work off those to recreate the UI.
Attempting to share the underlying artifacts just lead to a lot