Would GWT and/or incubator be interested in Run Time UiBinding

82 views
Skip to first unread message

TedM

unread,
Nov 12, 2010, 8:09:11 AM11/12/10
to Google Web Toolkit Contributors
Hi,

I made a run time UiBinding prototype. This allows for the creation
of forms or screens without having to recompile. Let me know if GWT
or the incubator is interested. If so I will release the code as an
open source project on google source.

Here is the prototype hosted on Google App Engine

http://gwt-binding-fly.appspot.com/

TedM

unread,
Nov 13, 2010, 9:00:42 PM11/13/10
to Google Web Toolkit Contributors
If it is helpful here is a video of me exampling how to use the demo.

http://www.youtube.com/watch?v=wDzuS7pnYJE

yves

unread,
Nov 14, 2010, 7:25:51 PM11/14/10
to Google Web Toolkit Contributors
May be this could be very interesting for some kind of applications.
Personaly I would be happy to have this kind of dynamic UI intergated
into GWT.

I have a question : what/how do you suggest to do in order to create
the link between the user interaction (e.g. click on a submit button)
to your code (e.g. to actually produce something) ?

GWT acquired GWTDesigner from Instantiations.com. But GWTDesigner (as
far as I remember when I used it almost 2 years ago) is not dynamic.
It allows only static prototyping. So GWTDesigner is not comparable to
what you created.

Here the added value, is the change one could provide to the UI on the
fly. Not usual in programming techniques !

Nice work.
Yves

TedM

unread,
Nov 14, 2010, 9:08:43 PM11/14/10
to Google Web Toolkit Contributors

Thanks,

I wasn't thinking in the line of GWTDesigner. The problem that I'm
solving at work is related to dynamic form definition. I want my
business user to be able to define forms and send them out, without
compiling and without things software installed on their locals. I'm
going to make a UI that plays through the browser (using GWT) that
will allow a non-technical person to design these forms.

personally think this idea would be a great addition to GWT, but I
don't want to start writing the OS version until I can talk to a GWT
or incubator guy.

The out comes of that talk will be one of the following.
1. They like the idea, and maybe I can bounce my architectural ideas
off them and then I build it with there input.
2. They already have this on their road map and don't need my help
3. They think it doesn't have value.

Do you know how I can get in contact with someone from GWT?

Chris Conroy

unread,
Nov 15, 2010, 11:13:23 AM11/15/10
to google-web-tool...@googlegroups.com
Ted, this is the right list for this sort of thing.

I can't speak to the specifics of your project at the moment--though
you'd probably get a better response if you included a design doc
and/or code.

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

Christian Goudreau

unread,
Nov 14, 2010, 10:25:29 PM11/14/10
to google-web-tool...@googlegroups.com
3. They think it doesn't have value.
I would change this to either
1- It's out of the scope of GWT at the moment or 
2- They have other priorities and can't get it in the roadmap yet.

 Do you know how I can get in contact with someone from GWT?
I think you're at the right place, just be patient :D

Btw, just to tell that I'm also interested in something like that as I will have to design one soon for my own projects.

Cheers, 

On Sun, Nov 14, 2010 at 9:08 PM, TedM <ted.ma...@gmail.com> wrote:



--
Christian Goudreau

TedM

unread,
Nov 15, 2010, 11:42:43 AM11/15/10
to Google Web Toolkit Contributors
The current implementation has the following functionality

1. dynamic forms
2. dynamic workflow
3. submission of form data
4. submission of attachments
5. client and server validation

And UI editor on the way.

But the current implementation is a project that I'm the architect
for. The prototype I put on Google App Engine is a Prototype based on
a prototype that I used to sell the idea to my company.

To open source this, I would like to do it in the following order.
1. Schedule a meeting with you Google guys the first or second week of
December
2. Draw up my designs and clean up my prototype.
3. Then I'll meet with you guys so I can get my design and vision
aligned with yours.
4. Then I'll build it to your vision

What do you think?

TedM

unread,
Nov 15, 2010, 11:49:25 AM11/15/10
to Google Web Toolkit Contributors
Thanks Christian,

I just started a dialog with Chris Conroy. Hopefully it will be
fruitful. Based on the feed back I'm getting this is a very common
problem.

I'm hopeful, I get to do this and get to do it in alignment with the
GWT vision.

John Tamplin

unread,
Nov 15, 2010, 11:56:05 AM11/15/10
to google-web-tool...@googlegroups.com

This is just a general comment from me personally -- I recognize that
there are times that you need dynamic functionality, but realize that
you pay a significant cost for it. Typical structures used to handle
dynamic content don't optimize well, and the compiler is unable to
remove a lot of code because it might be used depending on the data
received from the server.

Personally, when you can get away with it, you are much better off
either generating static code from dynamic data (which of course means
recompiling your app) or rendering the dynamic parts on the server. I
don't know if either of those are feasible for your use case.

Just because something is expensive doesn't meant it shouldn't be in
GWT -- if what you need to do is expensive, that doesn't change the
fact that you still need to do it. However, it would need to be done
in a way so that most people, who do not actually need that
functionality, do not wind up using it by mistake or paying the cost
because some library they use does. An example is reflection -- it
would be possible to implement reflection in GWT, but the problem is
that then almost all of the useful optimizations the compiler does
goes away. You can never remove a method that isn't referenced
(including after inlining it where you can) because there might be a
reflective call to it, you can no longer tighten argument types based
on the callsites, etc. So, rather than promoting functionality that
people definitely want but encourages them to write code that compiles
poorly, we chose to leave out reflection.

--
John A. Tamplin
Software Engineer (GWT), Google

Amir Kashani

unread,
Nov 15, 2010, 1:44:45 PM11/15/10
to google-web-tool...@googlegroups.com
Ted,

Are you familiar with the XForms specification? I think the original goal was to get browser vendors to implement it to replace HTML forms, which doesn't seem to be happening, but it's a very solid in dealing with a lot of the use cases of form creation pretty gracefully. EMC even has a GWT implementation of the spec that's meant to be used with one of their products, though it's not open source: https://community.emc.com/docs/DOC-3100. I think there are other open-source JavaScript implementations out there.

Anyway, it'd might be interesting to have an open-source GWT implementation available.

- Amir

TedM

unread,
Nov 15, 2010, 2:04:40 PM11/15/10
to Google Web Toolkit Contributors
Thank you, John for your post. Let me see if I can summarize your
concerns and then I’ll show you how my solution takes your concerns
into account.

Adding dynamic functionality may come at a global cost:

The example you used is reflection, which I think is a perfect
example of a dynamic functionality that would impact performance even
if the functionality wasn’t used. I would also agree with you, global
performance is paramount and should not be sacrificed lightly.
Now I believe I have taken this view point into my design. What you
see as dynamic in the demo is nothing more than a special widget
(Let’s call it the renderer Widget) that takes in HTML (with special
span tags) and then injects widgets into that HTML.
So with this design you can see that the renderer widget is not like
the reflection functionality. If the rendering widget is not used in
the program then it will have no impact on the compiled code base. If
it is used in the code base, its impact (in terms of performance) is
limited to the rendering of the form. Once the rendering is done then
only normal GWT or GXT widgets remain alongside some metadata that is
used for the save button.

Dynamic Vs Compile:
You note, that doing things at compile time can lead to much better
optimizations.
On this note I also agree with you. Compiling should always be
preferred over dynamic, unless it is the nature of the thing you’re
building is to change. An example in GWT that I can use is the
FlexTable. The FlexTable is designed for a user that wants to be able
to change a grid like structure on the fly. I see my renderer widget
in a similar light as the FlexTable design.

So let me know if my comments have any merit, if you have any
questions, if you have any objections.
Side note I checked out your train games, pretty cool. I’m also an
aspiring game developer and CGI artist.



On Nov 15, 11:56 am, John Tamplin <j...@google.com> wrote:

TedM

unread,
Nov 15, 2010, 2:06:52 PM11/15/10
to Google Web Toolkit Contributors
Yeah I'm not a big fan of XForms. I don't have my thought summarized
at the moment. Over all it's an outdated, unsupported standard that
doesn't have much momentum.

On Nov 15, 1:44 pm, Amir Kashani <amirkash...@gmail.com> wrote:
> Ted,
>
> Are you familiar with the XForms specification? I think the original goal
> was to get browser vendors to implement it to replace HTML forms, which
> doesn't seem to be happening, but it's a very solid in dealing with a lot of
> the use cases of form creation pretty gracefully. EMC even has a GWT
> implementation of the spec that's meant to be used with one of their
> products, though it's not open source:https://community.emc.com/docs/DOC-3100. I think there are other open-source
> JavaScript implementations out there.
>
> Anyway, it'd might be interesting to have an open-source GWT implementation
> available.
>
> - Amir
>

Chris Ramsdale

unread,
Nov 15, 2010, 2:13:37 PM11/15/10
to ted.ma...@gmail.com, google-web-tool...@googlegroups.com
This looks very interesting, indeed. Quick question though, how would one go about hooking up event handlers to the views that are bound on the fly? Say I wanted to do something trivial like validating user input in a cell?

-- Chris

TedM

unread,
Nov 15, 2010, 3:11:50 PM11/15/10
to Google Web Toolkit Contributors
Good good, you guys are so on top of things. I don’t know if I can
explain everything in text, I much prefer a white board, but I will
try.

Here is the high level process that I take to generate the dynamic
content.
1. Compile time I define what dynamic widget are available
2. Runtime - Put the dynamic HTML into a special location.
3. Runtime - Iterate through the special span tags, doing containers
before widgets
a. As I’m creating widgets I’m making two lists: value containing
widgets, post render widgets (post render widgets are marked with an
interface)
4. Runtime – After rendering I iterate through all post process
required widgets.
a. Here is where widgets and link up. In my demo the detailed
table example is an example of this.

I’m sure I missed a step or two but this summarizes the sprite of what
I’m doing.

If you want Chris I can drive down to atlanta and walk you through my
design. I've never been to a Google building, it kind of a dream of
mean :) I've heard the food is very good.


On Nov 15, 2:13 pm, Chris Ramsdale <cramsd...@google.com> wrote:
> This looks very interesting, indeed. Quick question though, how would one go
> about hooking up event handlers to the views that are bound on the fly? Say
> I wanted to do something trivial like validating user input in a cell?
>
> -- Chris
>

TedM

unread,
Nov 15, 2010, 7:45:38 PM11/15/10
to Google Web Toolkit Contributors
I think I read your question wrong.

I was thinking you meant an event handler between widgets. Like one
widget reacting to events from another widget.

Now I see you are talking about injecting listeners to do custom
validation. Hmm while I’m sure there are many ways of going about
it. I don’t think the core design prohibits these types of
injection.

Here are two ways it could be done, one not so good and the other
good.

Self validating widgets: You make an input widget that has self
validation logic. Like the reg x validation logic in the GXT
textField widget. Now I think this is the simplest way to do
validation but it has huge limitations. It can’t tell you if the form
is valid enough to submit, and it can’t validate across input fields.

Global validating widget: Here you make a widget whose main goal is
validation or at least keeping track of validation state. It may
handle the logic to display validation errors. It would be able to
determine if the form is valid enough to submit even in the case of a
multi-page form. It could use the post rendering process loop to
create listeners to the value widgets. I don’t think it would be hard
to implement and I don’t think it would add much over head.

Let me know if I gave you the answer you were looking for :)
> > > I made a run timeUiBindingprototype.  This allows for the creation

TedM

unread,
Nov 17, 2010, 8:47:18 AM11/17/10
to Google Web Toolkit Contributors
The thread seemed to stop without a conclusion. Is there any interest
to continuing the idea of dynmic uibinding?

On Nov 15, 2:13 pm, Chris Ramsdale <cramsd...@google.com> wrote:

TedM

unread,
Nov 18, 2010, 12:33:32 AM11/18/10
to Google Web Toolkit Contributors
Hi Chris,

I did what you said.

1. I took a couple of hours and I started up a Google Code project
called gwt-binding-fly. In it I added enough source to convey how
easy and simple the solution is. http://code.google.com/p/gwt-binding-fly/
2. I removed all the GXT stuff and made it pure GWT, with enough
flexibility to work with GXT and SmartGWT.
3. I also made a video walking you through the demo and the code.
http://www.youtube.com/watch?v=R1OFfmUI6ko

If you or anyone else has any questions or comments please send them
my way.

Ted Malaska

Chris Conroy

unread,
Dec 1, 2010, 12:10:40 PM12/1/10
to google-web-tool...@googlegroups.com
Sorry for the delay in responding.

I think that while this pattern may be useful for some users, it's probably not something we would want to encourage everyone to use by making it part of GWT proper. There are nontrivial runtime costs, you lose static analysis, and this seems ripe for XSRF if not handled with great care, etc..

In the general case, it would be a lot better to use the existing tools to accomplish the same thing: have the form designer install GPE and use DevMode refresh to iterate. Also note that GWT Designer may suit your needs: http://code.google.com/webtoolkit/tools/gwtdesigner/index.html


asif...@gmail.com

unread,
Sep 7, 2013, 12:21:44 AM9/7/13
to google-web-tool...@googlegroups.com
Hi Ted,

This is exactly what i was looking for using in one of my projects.

I tried the source at http://code.google.com/p/gwt-binding-fly/  - but this doesn't work at smoothly as
http://gwt-binding-fly.appspot.com/
is the code base different?

Regards

Thomas Broyer

unread,
Sep 7, 2013, 4:34:52 AM9/7/13
to google-web-tool...@googlegroups.com


On Saturday, September 7, 2013 6:21:44 AM UTC+2, asif...@gmail.com wrote:
Hi Ted,

This is exactly what i was looking for using in one of my projects.

I tried the source at http://code.google.com/p/gwt-binding-fly/  - but this doesn't work at smoothly as
http://gwt-binding-fly.appspot.com/
is the code base different?

Note: this project is 3 years old, and does not seem to have been updated since then.
The GWT-Contrib group also is not the appropriate place to ask for support (particularly for a 3rd party project); please contact the author directly.
Reply all
Reply to author
Forward
0 new messages