UIBinder Benefits?

[spierce7]

Does using the UI Binder provide any benefits? I watched some of the I/
O conference, and it seemed like they made reference that the UI
Binder using the browsers native rendering engine (or something like
that), and it being a lot faster, but they didn't really specify
whether that was the layout panels, or using the ui binder.

What are the benefits to using the UIBinder, and where can I learn to
use it?

[Jaroslav Záruba]

http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html

I think you will have idea of the benefits once you start reading that. :)

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[spierce7]

thanks :-)

On Jun 20, 9:39 pm, Jaroslav Záruba <jaroslav.zar...@gmail.com> wrote:
> http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html
>
> I think you will have idea of the benefits once you start reading that. :)
>

> On Mon, Jun 21, 2010 at 3:23 AM, spierce7 <spier...@gmail.com> wrote:
> > Does using the UI Binder provide any benefits? I watched some of the I/
> > O conference, and it seemed like they made reference that the UI
> > Binder using the browsers native rendering engine (or something like
> > that), and it being a lot faster, but they didn't really specify
> > whether that was the layout panels, or using the ui binder.
>
> > What are the benefits to using the UIBinder, and where can I learn to
> > use it?
>
> > --
> > 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-we...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

[Gal Dolber]

Beside of how easier its to write layouts in xml instead of java and the fact that you can easily embed css, images and other resources, if you use uiBinder with HTMLPanel you will get the best effortless performance with gwt.

2010/6/20 spierce7 <spie...@gmail.com>

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Stefan Bachert]

Hi,

I don't use UiBinder in general. It may be nice for some hacks.

UiBinder has a lot of problems
* a further language. No way to debug it
* limited to a set of widgets
* 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)
* no clear separation, no SoC. A big bunch of widgets and css-styles.
* no separation of theme/skin

When you watch the video with Ray Rian (gwt wave, discussion) you
clearly read between the lines that he doesn't like UiBinder, too.

The only advantage I see, it is faster to create a fragment of HTML
code than to build it via java/javascript code. But how often you will
create a html-structure? In a good design this will rarely happen.
And performance is one but the only design goal.

Stefan Bachert
http://gwtworld.de

[Sripathi Krishnan]

I think I disagree with you on almost all points. I have been using UIBinder much before GWT2.0 was officially released, and I think to use GWT straight-from-trunk to leverage UIBinder was the best architectural decision we made.

a further language. No way to debug it

Its the language of the web. If you are building websites, you ought to know html. There is no escaping that fact. And because it is HTML, debugging layout problems is just a matter of pulling out tools like firebug and the like.

limited to a set of widgets

.. but you are free to develop and use your own widgets. Besides, you have the full power of HTML. And, when it comes to widgets, its GWT in general which is poor; it has nothing to do with UiBinder. I mean, there are only 4-5 widgets that are supported by GWT but not by UIBinder.

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). no clear separation, no SoC. A big bunch of widgets and css-styles.

It actually is the best possible separation of concerns. Graphic designer works on the *.ui.xml - its just html, so he doesn't need to learn anything new. The developer works on the corresponding *.java file - he doesn't care about the layout or styling information. Both teams make changes almost independently, and its best utilization of each teams skills.

When you watch the video with Ray Rian (gwt wave, discussion) you clearly read between the lines that he doesn't like UiBinder, too.

Er, no. I certainly didn't read such a message.

But how often you will create a html-structure? In a good design this will rarely happen.

I find myself creating or changing HTML a lot frequently than changing the logic. Again, as I said, you are building for the browser, and there just isn't a way to escape HTML. Embrace html, and you will surely be a lot more productive. 

And performance is one but not the only design goal.

Agree that performance is not the only goal. But when you make a web-application (think gmail) that will not be refreshed/reloaded for long time periods, you cannot afford to perform DOM manipulations all the time. innerHTML is order of magnitudes faster than corresponding dom insertions..

--Sri

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

I think the decision to build from gwt trunk was the best architectural decision we took

[Tristan]

One key benefit I realized recently is having another developer come
in and style up the application. No need for anything but opening
UiBinder files and adding some css in different places, hitting
refresh and seeing how it looks. No need to understand framework used,
any logic code, nothing. That's pretty cool.

On Jun 21, 9:46 am, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .

[rakesh wagh]

uibinder separate layout out of your ui. pre uibinder we would use
inner class to create hierarchy like structure for layout right inside
java! That kind of code would look bit messy and unstructured to some
one who is not familiar with the style of programming. As a developer,
I would like to keep complete control with me and avoid more moving
parts, especially non debug-able xml code!

But in a way your java code looks much cleaner with uibinder. Since
uibinder is responsible only for laying out your components, it nicely
separates itself from the corresponding java class. Once you get used
to it, you start liking it. When uibinder was introduced, I was
hesitant myself but now I have adopted it. In fact I am craving for
better support of some panels and widgets. Gwt programming is such
that in most cases(unless you go out of the way) you end of creating
not more than one or 2 pages of ui.xml files. hence uibinder files are
very readable and usable!

Infact my question is, why xml? why not yaml or
json?

Rakesh Wagh

[Jaroslav Záruba]

On Mon, Jun 21, 2010 at 9:43 PM, rakesh wagh <rak...@gmail.com> wrote:

Infact my question is, why xml? why not yaml or json?

Because HTML is de-facto XML? And given UiBinder is mix of HTML + the UI-definition the choice has been obvious, IMO. Not speaking of data-structure definition, format validation, transformations - i.e. overall support.

I don't really see single reason for using anything else.

Rakesh Wagh

On Jun 20, 6:23 pm, spierce7 <spier...@gmail.com> wrote:
> Does using the UI Binder provide any benefits? I watched some of the I/
> O conference, and it seemed like they made reference that the UI
> Binder using the browsers native rendering engine (or something like
> that), and it being a lot faster, but they didn't really specify
> whether that was the layout panels, or using the ui binder.
>
> What are the benefits to using the UIBinder, and where can I learn to
> use it?

--
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-we...@googlegroups.com.

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Andrew Hughes]

Almost all of the "problem's" listed below are bad advice and I suggest you disregard them. Except for the "it's a graphic designer mindset" - this statement is correct. Thankfully we no longer need to code our layout and style in java!

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

@UiField(provided=true)

You then need to programatically decide/code when the uibinder should be called.

I would still recommend it.

[Stefan Bachert]

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);
}

[Blessed Geek]

Looking at your annotation, I find that I have to learn yet another
language.
I mean learning the annotation style as a language.

UiBinder is in XML and if you are familiar with XML, it's a breeze to
understand what's going on.

For the many many years doing distributed computing in industrial
environment - I find the unfortunate situation that data come in many
formats. There are log sheets that each vendor equipment invented with
their own respective formats. Frequently, the same equipment maker
willy-nilly comes out with a slight variation just because they have a
new line of models. Some are text, some are XML. if you do not strive
to be familiar with XML, you don't get to work.

So, every time I need to write a data loader for a piece of equipment,
should I have complained to management - I have to learn another
language, sir/maam?

Moreover, databases I encountered are of differing schemata of course.
Getting familiarized with an XML schema is similar to encountering yet
another database schema. I am personally guilty of inventing more
database and XML schemata (the plural for schema is schemata,
http://h2g2java.blessedgeek.com/2010/03/data-is-already-plural.html)
and adding to the plethora of "new languages" people who worked with
me had to learn.

For those of us who've had the misfortune of having to frequently work
with deciphering new XML and database schemata, which in your sense -
frequently having to learn new languages, UiBinder comes as natural as
mother tongue. So my condolences that you find UiBinder difficult for
you due to your less exposure to XML. It is indeed an unfortunate
situation that the people who came out with UiBinder did not take into
consideration that not all people are familiar with XML or are
resonant to data schemata. After all, UiBinder inventors probably made
a high presumption that every and any one using GWT has an industrial
purpose to using it.

Fortunately for me, and to your undue inconvenience (my apologies
again), there must be a lot of programmers out there who are like-
minded with me about the convenience of UiBinder due to our
inexplicable and mysterious bias towards XML. I think it is safe for
me to say that I am representative of those appreciative of UiBinder -
that our tacit complain are the following mysteries: Having invented
such a wonderous framework,

- why did the UiBinder inventors forgot about the need to provide a
means to register custorm parsers?
- why did they not realise the extreme inconvenience of not being able
extend Uibinderable classes properly?

Once these two issues are settled - hmmm ... there seems to be no
bounds to what my enthusiasm could do with UiBinder.

[jocke eriksson]

Great post!

Jocke

2010/6/23 Blessed Geek <bless...@gmail.com>

[Chris Boertien]

That has to be the most disturbing use of annotations I have ever
seen... on so many levels...

[Stefan Bachert]

On Jun 23, 7:49 pm, Blessed Geek <blessedg...@gmail.com> wrote:
> Looking at your annotation, I find that I have to learn yet another
> language.

Annotation are regular java. And UiBinder is using annotations, too.

> I mean learning the annotation style as a language.
>
> UiBinder is in XML and if you are familiar with XML, it's a breeze to
> understand what's going on.

You missed the point. XML is a totally different language than java
and it is not debuggable because pure declarative.
Java is much more user readable than XML.

>
> For the many many years doing distributed computing in industrial

> environment ...

You are going off topic, and you are not debating in honest way.

> Once these two issues are settled - hmmm ... there seems to be no
> bounds to what my enthusiasm could do with UiBinder.

Ok, you won't be able to use your gui definition to generate more
programming artefacts.

You seems to feel well in the dead end, your choice.
I do not intend to live in the dead end, my choice.

Stefan Bachert
http://gwtworld.de

[Sripathi Krishnan]

Lets try to discuss the statement "XML is declarative, and therefore not debuggable. UIBinder uses XML, and therefore, is not debuggable".

Totally agree on the first part of the statement - XML is a mess if you put logic into it. But, here is the key point - you cannot put logic in *.ui.xml even if you wanted to. There just isn't any way to do so. If you have seen the design notes, the GWT does not/will not ever allow things like if statements and while loops into *.ui.xml. The logic of your application stays 100% in java code, and is 100% debuggable.

Lets pursue debugging in java a bit more. Say you have this fragment in *.ui.xml 

<g:HTMLPanel><div class="news">Good News! Click the button</div><g:Button ui:field="clickMe"/></g:HTMLPanel>

Assume that you wrote the equivalent java code for that. Now you are testing, and you see the text is not appearing in red color as it should. Tell me, how will you debug that in Eclipse? You can't - its a UI issue, and you have to mess with tools like firebug to figure out why the particular css class does not apply.

UIBinder is no new language. In fact, it isn't a programming language at all. Think of it is an intelligent way to externalize your html markup and css.

--Sri

Stefan Bachert
http://gwtworld.de

--

[Andrew Hughes]

There's some good doco on this on the GWT site....

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

* limited to a set of widgets

FALSE: the only requirement to attach a widget in a ui.xml is that it is a widget.

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

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

* no separation of theme/skin

*FALSE: you can switch the (ui.xml) template file or CssResource several ways, and you can always load @external styles in the css/ui.xml or programatically set/implement them.

Hope that's the factual information you were looking for :)

--

[Blessed Geek]

On Jun 24, 11:15 am, Stefan Bachert <stefanbach...@yahoo.de> wrote:
You are going off topic, and you are not debating in honest way.

Nope, never meant to debate but simply to relate why I am
"dishonestly", mysteriously, inexplicably biased towards XML.

You are looking to win a debate, I see. Sorry, you win the debate. I
concede.

I wasn't debating but attempting to persuade why you too might need to
engage in being familiar with "dishonest" use of XML.

[Stefan Bachert]

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,

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

[Stefan Bachert]

Hi Sri,

rewind where the discussion starts from

readability:
I state java is much more readable the xml.
readablity improves understanding.
Could you agree with me?

debuggability
the understanding of a declarative language depends totally on the
documentation
(We all know that document might missing, wrong, incomplete,
misleading, oh, yes sometimes it is even correct ;-)
while for an imperative language debugging is a further way to get
insights, to see what is going on.

debuggability improves understanding.
Could you agree with me?


The most important advantage of the generator approach is, to be able
to drive more generators, or extend the existing one.

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

I do see no way to use UiBinder for that.

Do you have an idea how to generate such things using the UiBinder
definition?


Stefan Bachert
http://gwtworld.de

------------------------------------------------------------



On Jun 24, 10:57 pm, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:

> Lets try to discuss the statement "XML is declarative, and therefore not
> debuggable. UIBinder uses XML, and therefore, is not debuggable".
>
> Totally agree on the first part of the statement - XML is a mess if you put
> logic into it. But, here is the key point - you cannot put logic in *.ui.xml
> even if you wanted to. There just isn't any way to do so. If you have seen
> the design notes, the GWT does not/will not ever allow things like if
> statements and while loops into *.ui.xml. The logic of your application
> stays 100% in java code, and is 100% debuggable.
>
> Lets pursue debugging in java a bit more. Say you have this fragment in
> *.ui.xml
> <g:HTMLPanel><div class="news">Good News! Click the button</div><g:Button
> ui:field="clickMe"/></g:HTMLPanel>
>
> Assume that you wrote the equivalent java code for that. Now you are
> testing, and you see the text is not appearing in red color as it should.
> Tell me, how will you debug that in Eclipse? You can't - its a UI issue, and
> you have to mess with tools like firebug to figure out why the particular
> css class does not apply.
>
> UIBinder is no new language. In fact, it isn't a programming language at
> all. Think of it is an intelligent way to externalize your html markup and
> css.
>
> --Sri
>

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

[Jaroslav Záruba]

On Fri, Jun 25, 2010 at 7:28 PM, Stefan Bachert <stefan...@yahoo.de> wrote:

Hi Sri,

rewind where the discussion starts from

readability:
I state java is much more readable the xml.
readablity improves understanding.
Could you agree with me?

Not when it comes to designing UI. To be honest, such claim almost sounds funny to me.