any plans to offer java bean support in future?

5 views
Skip to first unread message

mwaschkowski

unread,
Oct 3, 2008, 8:50:15 AM10/3/08
to Google Web Toolkit
Hi All,

I've been using a 3rd party wysiwyg tool to create my gwt interface,
and one thing I've run into is that gwt does not support java bean
type customization. The following was suggested:
"General JavaBean support would be good which would include
standardize support for property accessors, default constructors,
custom editors, customizers, Beans.isDesignTime(), etc."

see:
http://www.instantiations.com/forum/viewtopic.php?f=11&t=2174&sid=301959ff86789c33cea2e71c1b58da83

The thing that I would need is custom editors. Would there be any
plans in the future to support this kind of thing?

Thanks very much,

Mark

Alex D

unread,
Oct 3, 2008, 3:51:19 PM10/3/08
to Google Web Toolkit
Why would you need this kind of code in GWT?

On Oct 3, 3:50 pm, mwaschkowski <mwaschkow...@gmail.com> wrote:
> Hi All,
>
> I've been using a 3rd party wysiwyg tool to create my gwt interface,
> and one thing I've run into is that gwt does not support java bean
> type customization. The following was suggested:
> "General JavaBean support would be good which would include
> standardize support for property accessors, default constructors,
> custom editors, customizers, Beans.isDesignTime(), etc."
>
> see:http://www.instantiations.com/forum/viewtopic.php?f=11&t=2174&sid=301...

mwaschkowski

unread,
Oct 5, 2008, 2:13:52 PM10/5/08
to Google Web Toolkit
So the gwt framework would, using established stanards (ie.
javabeans), allow for improved tool support.

Any plans?

gregor

unread,
Oct 5, 2008, 3:35:30 PM10/5/08
to Google Web Toolkit
Hi Mark,

GWT (client side) is limited in that it executes in javascript.
Javascript does not support reflection, and it is reflection that
makes the bean specification, Tomcat, application servers etc etc
work. It is also what makes "binding" domain classes to UI widgets
work in Swing, SWT etc. In a web application running in a browser this
is not possible (or rather not viably implementable in javacript
AFAIK).

It is possible to buck this using e.g. Java applets, Adobe Flex, or
Active X controls, bit all these require installation of native
browser plug-ins. This problem is acutely felt in the Java world
because e.g. Hibernate managed persistent entity classes use
reflection and proxies extensively, so they are not translatable to
javascript by the GWT compiler, and it is difficult to see at the
moment how they could be, although many people would wish it so.

Your point is well made, but given that a solution must perforce
revolve around a single OS/language/browser etc, or accepted
standards, who should establish those standards: Google. MS, Adobe,
IBM, Oracle? Maybe W3C.

My view is that DHTML is about as close as you get to a universal
standard and GWT makes a pretty good fist of implementing it,
deficiencies notwithstanding.

regards
gregor

Thomas Broyer

unread,
Oct 6, 2008, 5:20:14 AM10/6/08
to Google Web Toolkit

On 5 oct, 21:35, gregor <greg.power...@googlemail.com> wrote:
> Hi Mark,
>
> GWT (client side) is limited in that it executes in javascript.
> Javascript does not support reflection,

Er, "JavaScript does not support reflection" ???

GWT (by design) doesn't generate "reflectable" code, and doesn't
provide reflection APIs, but you can't blame JavaScript. It's
reflection that drives all those cross-browser pure-JavaScript
frameworks (if (window.XMLHttpRequest) { ...use XMLHTTPRequest... }
else if (window.ActiveXObject) { ...use new ActiveXObject... }).

> and it is reflection that
> makes the bean specification, Tomcat, application servers etc etc
> work. It is also what makes "binding" domain classes to UI widgets
> work in Swing, SWT etc. In a web application running in a browser this
> is not possible (or rather not viably implementable in javacript
> AFAIK).

I think the initial request was mainly for design-time support (custom
editors, not data-binding), i.e. Java-only (not JavaScript).

AFAICT (I don't know java.beans.* actually), some of it is already
possible. Just exclude your *BeanInfo, *Editor, etc. classes from Java-
to-JavaScript compilation:
<source path="client" excludes="**/*BeanInfo.java, **/
*Editor.java" />

Of course, things like EventHandler.create(...) cannot be done
(probably using a generator, but with some important amount of work
for very limited benefits, IMO).
Reply all
Reply to author
Forward
0 new messages