Tool to convert HTML in GWT widgets
553 views
Skip to first unread message
Davi Pires
Nov 24, 2009, 4:32:08 PM11/24/09
to Google-We...@googlegroups.com
Hi all,
In my company, we have been working with GWT for almost a year,
developing a ridesharing application (http://www.bigoo.com.br). I
really can't overstate how much we enjoy developing in java, using
familiar tools, debugging in hosted mode, and so on. But one thing
that has really bothered us for a long time is the dificulty of
integrating the work of developers (who write the code that eventually
outputs the HTML) with the work of designers (who write CSS).
Eventually we came up with a method where the designer gave the devs
an HTML fragment that worked as a 'contract' between their codes. The
devs had to write the GWT code that instantiated the widgets and set
ids and styles according to the spec. It worked, we did the job, but
there were lots of problems on the way:
- every little change to the 'contract' (new id, new classes) had to
be implemented by the developer. Therefore, there was a significant
delay between the designer's writing of the css and it being reflected
on the system.
- the designer felt rather demotivated by not having control over
generation of the UI.
Well, I guess some of these problems have already been mentioned here.
I won't dwell on it anymore.
Recently we implemented a small tool to help us overcome this problem.
In short, the designer writes the specs in an extended subset of HTML,
outside of the java code, in a properties file. This file is processed
by a generator we wrote that outputs the java code needed to
instantiate the gwt widgets corresponding to that spec.
In the GWT code we can retrieve each subnode of the tree (or
'subwidget') by the id, and add to it the appropriate handlers, or set
any other property.
We have automated the instantiation of the widgets, their addition the
the corresponding parents, the setting of a few properties such as
ids, classes, titles, value and enabled. It has allowed us to
reimplement complete pages, with all the interaction we had before,
significantly speeding up the development process, reducing the size
of the code, making it more readable, and increasing developer and
designer satisfaction.
I'd like to ask the community if anyone is interested on such a tool.
We are planning on opening up this code, but it still needs some work.
If it's of anyone's interest we would gladly open it.
Cheers,
Davi Pires
--
eco-blog: http://tarjaverde.wordpress.com
In my company, we have been working with GWT for almost a year,
developing a ridesharing application (http://www.bigoo.com.br). I
really can't overstate how much we enjoy developing in java, using
familiar tools, debugging in hosted mode, and so on. But one thing
that has really bothered us for a long time is the dificulty of
integrating the work of developers (who write the code that eventually
outputs the HTML) with the work of designers (who write CSS).
Eventually we came up with a method where the designer gave the devs
an HTML fragment that worked as a 'contract' between their codes. The
devs had to write the GWT code that instantiated the widgets and set
ids and styles according to the spec. It worked, we did the job, but
there were lots of problems on the way:
- every little change to the 'contract' (new id, new classes) had to
be implemented by the developer. Therefore, there was a significant
delay between the designer's writing of the css and it being reflected
on the system.
- the designer felt rather demotivated by not having control over
generation of the UI.
Well, I guess some of these problems have already been mentioned here.
I won't dwell on it anymore.
Recently we implemented a small tool to help us overcome this problem.
In short, the designer writes the specs in an extended subset of HTML,
outside of the java code, in a properties file. This file is processed
by a generator we wrote that outputs the java code needed to
instantiate the gwt widgets corresponding to that spec.
In the GWT code we can retrieve each subnode of the tree (or
'subwidget') by the id, and add to it the appropriate handlers, or set
any other property.
We have automated the instantiation of the widgets, their addition the
the corresponding parents, the setting of a few properties such as
ids, classes, titles, value and enabled. It has allowed us to
reimplement complete pages, with all the interaction we had before,
significantly speeding up the development process, reducing the size
of the code, making it more readable, and increasing developer and
designer satisfaction.
I'd like to ask the community if anyone is interested on such a tool.
We are planning on opening up this code, but it still needs some work.
If it's of anyone's interest we would gladly open it.
Cheers,
Davi Pires
--
eco-blog: http://tarjaverde.wordpress.com
jlw
Nov 24, 2009, 4:38:40 PM11/24/09
to Google Web Toolkit
+1
It's got my vote--sounds interesting. I actually started writing
something similar, but what I have does not approach the
sophistication of what you've described. It is still very much a
manual process.
It's got my vote--sounds interesting. I actually started writing
something similar, but what I have does not approach the
sophistication of what you've described. It is still very much a
manual process.
Yozons Support on Gmail
Nov 24, 2009, 5:34:16 PM11/24/09
to google-we...@googlegroups.com
How does it compare to the UIBinder in GWT 2? I've not used it yet, but understand it's an XML file format for building UIs. If they overlap, people will more likely prefer UIBinder, but if they do not, I'm sure others would be interested.
Sripathi Krishnan
Nov 24, 2009, 11:24:52 PM11/24/09
to google-we...@googlegroups.com
How does it compare to the UIBinder in GWT 2?
From the description, it is exactly what UiBinder does.
--Sri
2009/11/25 Yozons Support on Gmail <yoz...@gmail.com>
How does it compare to the UIBinder in GWT 2? I've not used it yet, but understand it's an XML file format for building UIs. If they overlap, people will more likely prefer UIBinder, but if they do not, I'm sure others would be interested.
--
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.
gwtfanb0y
Nov 25, 2009, 3:52:00 AM11/25/09
to Google Web Toolkit
This sounds very interesting to me, please open up the code for us.
sridhar vennela
Nov 25, 2009, 6:11:32 PM11/25/09
to google-we...@googlegroups.com
let me know. i can try. also attach some examples...
Davi Pires
Nov 27, 2009, 9:49:16 AM11/27/09
to google-we...@googlegroups.com
I confess that I didn't know about the UiBinder. But, now that you
mentioned, after taking a look at it, and discussing with the team we
are keeping with our own tool.
The main difference between the two approaches is that our language to
define the widget tree (which we call MHTML) does a best effort
approach to be as similar as possible to HTML. The purpose here is to
easen the conversion of the pure HTML code into something "parseable"
and easily and directly convertible to GWT widgets.
For example, while you need a <g:ListBox> tag to instantiate a ListBox
widget, in our case you would write directly the <select> tag. A <div>
tag is converted into a FlowPanel, <span>s in InlineLabels, and so on.
One thing that the UIBinder does that we don't do is the automatic
binding of the widgets into the parent class fields. In our tool, we
have to write a few lines that fetch the subwidgets by id, and store
them in the class fields. (Although, we are now thinking of
implementing the automatic binding on our tool too).
While discussing it in our team, everyone (specially the designer)
felt much more inclined to continue using our tool.
We will do some more work on improving the code, and open up its code soon.
Thanks for the feedback.
Cheers,
Davi Pires
--
eco-blog: http://tarjaverde.wordpress.com
mentioned, after taking a look at it, and discussing with the team we
are keeping with our own tool.
The main difference between the two approaches is that our language to
define the widget tree (which we call MHTML) does a best effort
approach to be as similar as possible to HTML. The purpose here is to
easen the conversion of the pure HTML code into something "parseable"
and easily and directly convertible to GWT widgets.
For example, while you need a <g:ListBox> tag to instantiate a ListBox
widget, in our case you would write directly the <select> tag. A <div>
tag is converted into a FlowPanel, <span>s in InlineLabels, and so on.
One thing that the UIBinder does that we don't do is the automatic
binding of the widgets into the parent class fields. In our tool, we
have to write a few lines that fetch the subwidgets by id, and store
them in the class fields. (Although, we are now thinking of
implementing the automatic binding on our tool too).
While discussing it in our team, everyone (specially the designer)
felt much more inclined to continue using our tool.
We will do some more work on improving the code, and open up its code soon.
Thanks for the feedback.
Cheers,
Davi Pires
eco-blog: http://tarjaverde.wordpress.com
Dhinakar Reddy Pothireddi
Nov 8, 2016, 5:15:38 AM11/8/16
to GWT Users, Google-We...@googlegroups.com
Please open up the code and help us to learn it. Thanks in advance.
Vassilis Virvilis
Nov 8, 2016, 5:49:03 AM11/8/16
to google-we...@googlegroups.com
From the subject I thought that somebody was asking for the "magical" tool.
By reading becomes evident that somebody has actually implemented the "magical" tool which is not magical after all just a lot of work, design, builtin assumptions and real life trade offs as all useful software.
Definitely it looks interesting. After all is like UiBinder done in html instead of xml.
By reading becomes evident that somebody has actually implemented the "magical" tool which is not magical after all just a lot of work, design, builtin assumptions and real life trade offs as all useful software.
Definitely it looks interesting. After all is like UiBinder done in html instead of xml.
Congrats.
--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsub...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
--
Vassilis Virvilis
Vassilis Virvilis
Nov 8, 2016, 5:50:12 AM11/8/16
to google-we...@googlegroups.com
Ooh! Now I saw it. The initial letter is from 2009. Sorry for replied to a zombie thread
VassilisTo unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
--Vassilis Virvilis
--
Vassilis Virvilis
Reply all
Reply to author
Forward
0 new messages