Vaadin in general is covered at http://www.vaadin.com, but basically it is a framework based on GWT that allows you to write portlets entirely in java (no HTML, no JS, and actually very little with respect to the portlet API), yet when they are deployed they are fast AJAX-based portlets (so they natively handle partial page updates, etc.).

Uses in the Liferay context? Well there are functional uses (creating AJAX portlets, business portlets, etc.) and there are environmental uses (have lots of java devs but few web/javascript gurus), etc. It's often not so much of what can you do with Vaadin as what you shouldn't do in Vaadin.

If you check my blog you'll see I have a chart portlet written in Vaadin, shows a chart in a page that responds to user events and would work for a dashboard presentation.

There's lots of good reasons to use Vaadin and some reasons not to. I don't think there's a general rule about it, however.

An entirely new plugin, it includes functionality not provided by the Arcusys version (theme editing/import/export, automatic upgrade of Liferay from V6 to V7, more explanations about the purpose of the control panel, automatic portlets upgrade when Vaadin version is changed, ...).

When would you use this instead of the all in one approach? That's actually covered in another blog. One is what happens when you use the "all in one" approach for two different portlets but one portlet is created with, say, 7.4 and the other is 7.5 and they are both on the same portal page? How can the browser resolve which version of the engine to run? Can both versions run in the same page? Using the shared environment, all portlets share the same version of Vaadin so these kinds of issues are avoided.

There's also duplication of resources. If you create a theme, you have to ship that with every portlet because nothing is shared. In the shared Vaadin environment, your theme can be global on the portal level, your portlets don't have to duplicate all of the code.

There's also widgetset concerns. If your two plugins each use a different set of add-ons, they'll each have their own compiled widgetset. When on the same portal page, will they play well together or will there be some incompatibility that crops up? In the shared environment, the widgetset is compiled at the portal level so all portlets share the same widgetset regardless if they use all of the add-ons or not.

I think the thing Vaadin was trying to resolve was the complexities of using Vaadin in the portal. The control panel was released for V6 in the Liferay 6 line, but there was no real explanation of what it was for or how to use it. I spent a great deal of time on V6 and the old control panel trying to figure out the add-ons, how they get deployed, how to update Vaadin in the portal and portlet level, theming, etc. The V6 control panel is crucial in using V6 in the portal, but for the life of me figuring all of that out on your own is a pain.

For the V7 control panel, I wanted to incorporate similar functionality from the old V6 and Arcusys control panel but provide significant add-on value such as conforming with the standard Liferay control panel theme, explaining all of the parts of the control panel and using the shared V7 environment, handling the auto upgrade from V6 to V7 (manually there's a bunch of steps you'd have to do to get it all done), etc.

If you're interested in the V7 control panel, I have a lot more blog posts here on Liferay.com covering it and it's various features.

And, as always, I'm more than interested in feedback and suggestions...

Hi again!

After further investigation appears that com.liferay.portal.servlet.filters.language.LanguageFilter is the one causing problems. If I turn it off, Vaadin portlets are working without issues, and if it is on it causes content encoding errors and js files are not loaded.

Maybe because LanguageFilter are processing js files which are compressed?
I need multi language support in portal, so I can't leave it off