Porting Large GWT Projects

[claude]

I have been working on a project that is largely under the radar at the
moment, so I have been lurking and using GWT since the first release,
without posting before. I wanted to take a moment to encourate the team
and to share a few observations that may be of use.

1) The GWT is a great toolset. I'm very impressed and have had a great
general experience with the toolkit. It is not without compromises or
quirks, however, most of them caused by browser ideosyncracies. What
makes this a viable platform is that the hooks are there to work around
anything. For example, limitations in the HttpRequest did not stop me
from using the same coding pattern to implement my own XmlHttpRequest
and XmlHttoResponseHandler to deal with XML. Because I need to
interoprate with non-Java back-end code, I could not rely on the Java
RPC mechanism. I would love to see an explanation or example of how the
RPC implementation could use alternate serialization mechanism to
support different protocols, however.

2) Our GWT application (on which I am the prime developer) is well over
200 client-side classes and porting to GWT 1.1 took less than a half
day (baring any new suprises I haven't found just yet). The change to
IndexedPanels impacted me greatly due to my use of custom layout
panels, and the change to the way elements are attached and detached
caused me some difficulty as well. However, the experience was bearable
and I will endeavor to find ways around remaining bugs while awaiting
the next release. I look forward to every enhancement.

3) There is frequent mention of the Generator API on in the
documentation and ocassionally on the forum. Hhowever, there is no
explanation anywhere on how these might be leveraged by developers. I
see the use of "generate-with" in the i18n descriptor but wonder how I
migth use this to overcome limitations from a lack of introspection
support. In effect, I'd like to avoid having to create model objects
that are used on the client and server with client or server-specific
code. Server objects can use AOP or wrapper mechanisms to decorate
POJOs but there is no similart option in GWT, though I have a hunch
there is more to it than meets the eye ;-)

4) I would like to contribute code to the community but there are a
couple of barriers. First, some relate to the organization I work for,
but we are working to resolve this. Second, there is no mechanism for
offering code to the Goodle group, which is what open source should be
about, at least in principle. I have, for example, a working
drag-and-drop engine, a windowing engine, XML-RPC code, layout
managers, a a numbe rof utility classes that I would like to offer when
it is possible to do so. Even if only for consideration in the GWT.
These will probably get released eventually, but one objective of open
source is to advance the framework more quickly. I see the current
process as limiting in several ways and would love to see things open
up WRT contributions.

5) I come from a prety deep Swing background (I used to write a column
for both Java Pro magazine and JDJ about Swing some years ago). I find
the GWT very exciting, and full of promisse. If only we could get those
browsers to stop being so quirky whenever we push the envelope... ;-)

My thanks to the group and keep up the good work.
I will try to be more active and post what I can when I am able...

[Marcos Araujo Sobrinho]

Hi Claude!

Nice to hear that from you. I´m working on a large project too and probably we will migrate all the presentation layer to GWT soon.

I have a question: How are you managing all the user interaction in your 200 client-side classes?
I´m going to have 2,000 "transactions" (ie: actions that an user can perform) in this application and I have no idea how to implement this using a single entry point, a single onModuleLoad and a single onHistoryChanged, without having a 25MB javascript on the client-side... :P

Any idea on how I can solve this issue?

Thanks!
Marcos

-----Mensagem original-----
De: Google-We...@googlegroups.com
[mailto:Google-We...@googlegroups.com]Em nome de claude
Enviada em: segunda-feira, 14 de agosto de 2006 18:47
Para: Google Web Toolkit
Assunto: Porting Large GWT Projects

[claude]

We've taken a portal-like approach in which functional elements are
modular, though potentially interoperable. I can't say I have to deal
with 2000 actions though. Clearly the Command Pattern will help and
there will be a need in your case to host different parts of the
applicaton on different web pages. I haven't tried this yet, but I
wonder how re-entrant GWT might be, such that an XmlHttpRequest could
theoretically load another GWT URL to handle modular functionality. You
can also consider using an IFrame to host subsections and explore
passing data across the DOM. It's too early in the GWT's lifecycle to
offer much in the way of best-practices.

[bruciadmin]

I hope to see some blogs written on this topic. I know I implemented
something which I think is nice and locks out multiple actions occuring
on models with asynchronous updates... but that's just my way of trying
to implement a nice solution - and I am sure there are better ways out
there. Then again, these lessons have been learned well from large
applications built on technologies like Swing, so any veteran Swing
programmers (like Claude) can probably bring a lot of value to these
discussions.

I'm sure if we see a few different blog format posts on the various
ways people solved the issue, we'll all come to a nice conclusion as to
what are the better ways of working with asyncronous updates and client
side actions.

[dman]

+1

[Adam T]

claude wrote:

>
> 4) I would like to contribute code to the community but there are a
> couple of barriers. First, some relate to the organization I work for,
> but we are working to resolve this. Second, there is no mechanism for
> offering code to the Goodle group, which is what open source should be
> about, at least in principle. I have, for example, a working
> drag-and-drop engine, a windowing engine, XML-RPC code, layout
> managers, a a numbe rof utility classes that I would like to offer when
> it is possible to do so. Even if only for consideration in the GWT.

Claude, some of the 3rd party libraries are good at distributing code
to the community - for example the GWT Widget Library that is used by
quite a few people (it has more in there than just widgets, for example
a controller for Spring integration and a few other things).

http://gwt-widget.sourceforge.net/

//Adam

[claude]

> Claude, some of the 3rd party libraries are good at distributing code
> to the community - for example the GWT Widget Library that is used by
> quite a few people (it has more in there than just widgets, for example
> a controller for Spring integration and a few other things).
>
> http://gwt-widget.sourceforge.net/
>
> //Adam

Thanks Adam.

I can't distribute code until the ownership issues with my employer are
addressed. They are supportive but there are other prioirites that have
pushed this back a little. Once I have that option, I will make
whatever code I can available somewhere.

I would like to encourage the GWT group to develop a contribution
system in which it is possible for others to offer code (which they may
chose to reject, of course). At least there would be a way to enhance
the base architecture (they would remain owners and gatekeepers in any
case so as to keep the vision consistent) but others could offer
solutions that should be part of the base infrastructure, possibly
lightening the load to a small degree. Even if contributed code only
serves to point the way to a working approach, that could be helpful I
think.

The libraries you mentioned do not address the need for modeling with
POJO's on the client side. I wrote an XML-RPC Spring Remoting solution
that does the trick on the server side and, because it plugs into the
Spring Remoting model, leaves me free to use alternate protocols with
relative ease (I have one for JSON for example, and the standard Spring
Remoting protocols are also available).

Ideally, something similar that can work with GWT is of interest. I
have tried using JS to get the at the properties of an object (a POJO
if you will) but the names are mangled so there is no way to do
introspection without a name map or avoiding method name compression.
In passing, I did notice that the toString and class names are
unmangled. What I'd love to see is the ability to take a model POJO and
serialize it using standard protocols (be they RMI, XML-PRC, JSON, etc)
without having to couple the protocol to the model before compilation.

[claude]

> Claude, some of the 3rd party libraries are good at distributing code
> to the community - for example the GWT Widget Library that is used by
> quite a few people (it has more in there than just widgets, for example
> a controller for Spring integration and a few other things).
>
> http://gwt-widget.sourceforge.net/
>
> //Adam

Thanks Adam.

[bruciadmin]

Hi Claude,

I'm not sure if this is what you mean, but I worked on an Ant task
which takes a Spring context (or group of contexts) and turns it into
the serialised form of bean creation, wiring and then initialization
statements - which can then be turned into a Javascript factory on the
client side. This has helped me enormously when configuring my beans on
the client side. It doesn't have all the benefits of a true Spring
container (aspect orientated programming would be a great "to have"
feature), but is better then just hand coding wiring statements.

http://sourceforge.net/projects/spring-gwt

I think if I'm serious about this project I'm going to have to write
some more documentation on it. But... is this the kind of thing you
were after?

Cheers,

David L