But I’m not sure about the details of migration/integration.
Our current application is an enterprise style application with lots of forms and tables.
The main navigation is handled by a big accordeon widget on the left hand side which acts
like a vertical menu/sub-menu. By selecting on of the “menu options” from the accordeon the right
hand side switches between different but similiar forms.
The whole application is built on top of GWT-EXT which is a GWT wrapper around ExtJS.
The GWT-EXT project
gwt-ext.com was stopped some time ago which is one of the reasons we need to migrate.
We use GWT-RPC and Spring on the server side.
Our idea for a migration goes like this:
Start with existing project
Make it run “inside” Vaadin (whatever this mean)
Migrate the application form by form
Release “mixed” versions of the app (GWT-EXT/Vaadin) to production in between
When there are no GWT-EXT forms anymore remove “infrastructure overhead” (GWT-RPC, etc.)
Is this a feasible strategy?
How can this be done in practice?
For example:
Should we embed Vaadin in EXT-GWT like this:
EXT-GWT accordeon
|-- EXT-GWT form 1
|-- EXT-GWT form 2
|-- Vaadin form 1
Or should we embed EXT-GWT in Vaadin like this:
Vaadin accordeon
|-- EXT-GWT form 1
|-- EXT-GWT form 2
|-- Vaadin form 1
How would I create the widgets?
I.e. How to create GWT-EXT widget inside Vaadin or Vaadin widget inside GWT-EXT?
In my opinion, this is the way to go for your application - it is simpler to embed GWT parts in a Vaadin application than the other way around, although the ExternalLayout add-on (if converted for Vaadin 7) might also allow embedding Vaadin forms in your existing application.
Assuming the forms of your application are quite independent of each other, one approach to make it run with Vaadin could be:
Replace GWT JARs with Vaadin JARs
Convert the whole GWT-EXT application into a single Vaadin component (with a Connector that does practically nothing)
Split the GWT-EXT forms into separate widgets and wrap them as Vaadin components (with almost empty connectors), replace the top-level accordion
Migrate the content form by form
This would allow you to test the application at each stage and fix problems one at a time rather than everything at once, and not commit to a full migration before you see how it is working.
As far as I know, there are no bigger examples of such conversions publicly available at the moment.
Hi Oliver, we are considering migrating from an existing GWT Application to Vaadin as well. My initial idea was to embedd Vaadin into GWT, but accoording to Henry the other way round is the way to go. Since this post is almost a year old, could you meanwhile use any of the mentioned approaches to migrate to vaadin.
I am also looking to do exactly the same thing. We have an existing application that relies on a library which is GWT based. The first thing I did was remove the gwt.jar file in the existing project and replace it with the appropriate Vaadin jars. This was not as easy as “drop it in” as vaadin packages gwt and 3rd party classes differently than gwt. Moreover, the existing application uses gwt-2.5.1 and the Vaadin release I am using is based off of gwt-2.6.1 – this brought about a number of issues with other libraries that also required upgrades in order to compile (which I won’t get into here).
Anyway, once I finally got GWT out and Vaadin in, upgraded the appropriate 3rd party libraries, and made some build file changes (since there is no true 1-to-1 GWT → Vaadin jar relationship) I was able to successfully build my project as well as run it and do some preliminary testing.
Now, I’m working on the hard part. As I see it I have a couple choices, similar to Henri’s suggestion:
Start with existing project
Make it run “inside” Vaadin (whatever this mean)
← done with this
Migrate the application form by form
← starting
Release “mixed” versions of the app (GWT-EXT/Vaadin) to production in between
← was planning to do this
When there are no GWT-EXT forms anymore remove “infrastructure overhead” (GWT-RPC, etc.)
The problem with this is that most of the dependent GWT library in the existing app is client-side which I want to avoid. Most of the functionality provided by this GWT library is already provided by server-side vaadin widgets, and I don’t want to convert this to a vaadin client-side application.
So my thinking is that I will remove the 3rd party library dependency and find where the build fails and “simply”
build new Vaadin based UIs for each of those components and change the references in the existing code to use the new all UI. Does this sound like a feasible plan? Is there something I’m missing by trying to remove all GWT client side code and replace it with a new Vaadin server-side UI?
As a followup, after reading the link in Henri’s post,
Integrating an existing GWT widget , I’m wondering whether I need to just leave the existing GWT components as is and do as that post suggests and create wrapper/connectors for them. Is there some advantage/disadvantage to that method?