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...
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-Web-Toolkit@googlegroups.com [mailto:Google-Web-Toolkit@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
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...
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.
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.
bruciadmin wrote: > 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.
> 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).
> 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).
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, 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).
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.
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.
