Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
Vaadin 7 alpha2 - RPC and Shared State
Vaadin 7 alpha2 contains significant changes in how communication between the server and the client connector is done. Communication is now based on RPC calls (server <-> client) and shared state (server -> client). The old UIDL and variable based API is provided only to ease migration of Vaadin 6 components.
Each component in Vaadin 7 has a shared state. The shared state is a standard Java bean that is automatically synchronized from the server to the client. You set the values on the server side and can read them on the client side without any additional code. This provides type safety and an easier programming model compared to the earlier paint mechanism in Vaadin 6.
All the Java types you use in the shared state must be available to the GWT compiler so you need to create them in the client side Java package. You can use standard Java types and custom beans in your shared state. You can have collections of custom beans in multiple levels. Do however note that polymorphism is not supported, the declared type is always used.
Remote Procedure Calls
Remote Producedure Calls can be made from the client to the server or from the server to the client. By defining an RPC interface you can get a generated proxy implementation on the calling side, which will automatically take care of that the method is called on the other side. Of course you need to implement the interface on the other side so there is some code to be executed.
The same type restrictions as for shared state apply.
Special Vaadin Type
There are some special Vaadin types (Component, Resource) that need special handling when used in RPC methods or in the shared state. See the tutorials for more information.
The communication in alpha2 has not been optimized. There is a lot of data sent between the server and the client. We will focus on optimizing the communications before 7.0 by sending only differences in state, shortening fully qualified class names etc.
There are some restrictions as what types work with shared state and RPC. Avoid typed arrays and enums at the moment; we should get the support there before the final version.
RPC methods currently need to have unique names (no overloading allowed)
You should not declare state classes as static inner classes in you connector class. Some class loaders have problem using them on the server side without trying the load the connector class, which fails as it references GWT classes (directly or indirectly).
For short examples on how to use the new features, check out the Vaadin 7 mini tutorials: https://vaadin.com/wiki/-/wiki/Main/Vaadin+7
For information on how to migrate from Vaadin 6 to Vaadin 7, see http://dev.vaadin.com/wiki/Vaadin7/MigrationGuide
This is an alpha release so we expect there to be bugs and still expect changes will be made to the API and functionality before the final 7.0.0 release. All your comments on the new features are welcome. Please post all Vaadin 7 related comments in the Vaadin 7 category of the forum.
Artur Signell: The shared state is a standard Java bean that is automatically synchronized from the server to the client. You set the values on the server side and can read them on the client side without any additional code.
Does "automatic" imply "no need to push" any more ?
Jean-François Lamy: Does "automatic" imply "no need to push" any more ?
No, automatic here just means that the framework takes care of the serialization and deserialization.
You still need to call requestRepaint after changing the state to let the framework know that the state has changed (this might still change, but for now it is needed). The changes to the state will then be included the next time a response is sent to the client. Vaadin 7 alpha4 will according to the plans provide server push functionality, either included in vaadin.jar or as an official add-on in the Directory.
How is all this expected to play when your Vaadin app is a Liferay portlet? I mean, is Liferay still going to be a first-class citizen in the Vaadin 7 world?
It sounds as if there's going to be a lot more GWT compiling going on than before, so it just makes me wonder if the model of having a nice pile of liferay-global GWT stuck away somewhere to serve all your portlets is going to remain a viable model.
Kirk Stork: How is all this expected to play when your Vaadin app is a Liferay portlet? I mean, is Liferay still going to be a first-class citizen in the Vaadin 7 world?
The status of the support for Liferay and portlets overall is unchanged. The only change is that support for the older Portlet 1.0 style portlets (JSR-168) is being dropped. Portlet 2.0 is still fully supported.
Kirk Stork: It sounds as if there's going to be a lot more GWT compiling going on than before, so it just makes me wonder if the model of having a nice pile of liferay-global GWT stuck away somewhere to serve all your portlets is going to remain a viable model.
The amount of required GWT compiling hasn't changed in any way as long as you don't make any radical changes to your own architecture. The new models should make it easier for the application developer to move application logic to the client side code in those cases where it makes sense, but doing so will still be fully optional.
Rest assured that the vision behind Vaadin is still that it should be possible to create web applications using only server side Java without worrying about what's happening in the browser. Part of this vision is that recompiling the widgetset is just something you need to do when you update to a new version of Vaadin or an add-on that your are using and that the Vaadin plugin for Eclipse can take care of this for you.
What about more than one Vaadin portlet in the same page? Current Liferay 6.1.0 fails a lot with this. Due to different lifecycle status between the shared Vaadin code and the Vaadin portlet applications, it's quite easy to get an error 404 ... UIDL.
Will this approach go on with Vaadin 7?
Will the new GWT 2.5 version be included in Vaadin 7?
Does GWT 2.5 allow to change the requirement of shared compiled widgetsets?
In a recent project with Liferay 6.1.0 I had to go 15 years back in my life and redesign portlets in the Liferay way: Generic portlet / MVC / Struts / spaghetti JSP.
There were some improvements to try to auto-extend sessions the Liferay way etc. in 6.7.10 (see issue #8305). Some more rework of session management (not only for portlets) was proposed for Vaadin 7 but might or might not make it in the schedule.
Vaadin 7 alpha 3 includes GWT 2.5 (built from release branch of GWT just before Google I/O, not exactly the final version at the moment) and will track GWT 2.5 improvements when approaching Vaadin 7.
It is already technically possible to use multiple widgetsets on a page with Vaadin 6.7 and 6.8 although this is not really documented - at the moment, you are mostly on your own if doing this. On a portal, the widgetsets should be served from a shared directory, though, even though different portlets can use different widgetsets if you remove the "portal level widgetset" parameter from your portal configuration.
Serving the widgetset from the portlet itself would probably require a custom GWT linker and some work in the portlet class, and serving them with a separate servlet in the same WAR as the portlet would require knowing the path for the servlet and communicating it to the client. Themes and widgetsets should be served from the same location.
Some further improvements to widgetset management are probably coming after Vaadin 7.0.
Will the Liferay IPC addon work with Vaadin 7?