Hi everyone

I recently came across with the following dilemma: I'd want to use Vaadin 6.8.1 but I'd also want to use Primefaces 3.x? The same is for the inner Alloy UI that is used with Liferay 6.x.

Question here is: Knowing that each of them has its pros and cons, which one do you recommend me? I am so inclined to use Vaadin because it is a very responsive. But I want your opinion as well, in a very infortant way.

Thanks in advance and looking forward for a clue on this regard.

Atte.

We're using vaadin almost exclusively. Creating vaadin-based apps is like building Swing applications, and our devs don't have to know the java side, javascript, plus whatever other technology for rendering views.

That said, some things in Vaadin portlets just takes time getting used to, and there are some inherent concerns:

1. Resource usage - I haven't gathered any metrics on this yet, but I need to know more about the impact of a lot of Vaadin portlets and the class loader. Normally you'd move frequently used jars to the global class loader so each portlet doesn't have a duplicate instance of the jar loaded into memory. I'm not sure how Vaadin would work in the global class loader, if such a move really saves much, ...

2. Adapters for Liferay SB entities and paging. SB interfaces support paging through lists (i.e. by passing starting and ending info), but the Vaadin containers only have adapters for JDBC paging. Since one doesn't do JDBC in portlets, you're left to your own devices for handling the paging.

3. Upgrades are somewhat of a pain. We do the vaadin.jar update via an EXT plugin, the /html/VAADIN updates using a hook (themes only, no widgetsets because we use the Vaadin controlpanel for liferay to handle that). For awhile there were regular and frequent updates to Vaadin (the 6.6 and 6.7 versions went through many iterations), and we kept current because the bugs fixed per release typically touched on things we were using.

4. Theming is a pain. Vaadin themes live outside of the Liferay theme, so rather than managing a single theme for your Liferay pages, you're now managing two themes.

5. Some things are just plain hard to do in vaadin. For example, we needed to show/hide a div depending upon whether the mouse was hovering over a gear icon. After numerous attempts at trying to do it correctly in Vaadin & CSS, we eventually had to use plain old Javascript to get it to work correctly (and it is not so easy getting Javascript control of Vaadin elements).

That said, we love the Vaadin visual editor. It's easy to construct a basic page using the visual editor, then flipping over to the code editor to wire up the event handlers. Since it's fully AJAX, page refreshes do not affect values user has entered in our Vaadin-based apps (server side has the info the user was in the process of entering).

It's a great little framework that we've had a lot of success with.

We don't use Vaadin for everything, though. Anything that requires a lot of visual appeal, we do in something with a little less weight (typically just JSP/Liferay MVC).

@David

Thank you very much for your time.
I have read and will take that into account.
I am precisely deciding on Vaadin.
One more thing, I am a newbie in Vaadin, would you help me on issues about it? I am trying to configure latest version in Portal and trying to make a portlet out of the Address book example (Vaadin example) but get no results.

Thanks.

I think I'm going to put together a wiki page on this, but here's the key info:

1. To use the latest vaadin, download the jar and replace the ROOT/WEB-INF/lib/vaadin.jar with the newer version (always name it vaadin.jar).
2. You should also download the vaadin liferay upgrade zip file. The contents of this file should be unzipped to ROOT/html/VAADIN as it contains the theme updates/bugfixes.
3. You should have the vaadin controlpanel for liferay installed in your system. After making any change (such as this), you must always go to the control panel and compile the widget set.
4. When adding new widgets, drop their jar files into ROOT/WEB-INF/lib, then use vaadin control panel (check the box for the widget to include) and compile the widgetset.
5. Your portlet should never have it's own copy of vaadin.jar, you should always use liferay-plugin-package.properties to pull in Liferay's version of the vaadin.jar (same w/ all of the plugins), and never have them in your own WEB-INF/lib directory.

Note that placing vaadin portlets on a page initially never seems to work out too well (at least for me, anyway). Do a page refresh and it will be there, though.

Thank you very much for this tips. BTW, do you have some example portlets using Vaadin and any other view technology so I can learn a little more about how to build Portlets at hand. I am researching (that is, newbie) porlet development, and as I advocate for Spring framework I lack knowledge in Spring Porlet MVC as I would like to use it.

I harness this opportunity to ask you other facts:

Why don't you recommend JDBC in porlet development?
Liferay Service Builder is useful, in my opinion, only if tables are stored in the same database as the portal, but what about tables stored outside Liferay database, i.e., suppose one table is for products and it cannot be stored in the same portal database, it has to be in another schema, thus to gather that information Liferay Service Builder cannot be used (in what I know), thus a service strategy must be implemented to access that table data, is it feasible, or what do you advice?

I don't have anything that I can share, although I am hoping to get some stuff into the marketplace so maybe I should get to work on it...

Spring and Vaadin are separate entities. Integrating them is fun. There are some addons from Vaadin which can help with the integration, but you really should know something about both for them to make some sense.

Well, separate questions should be posted as separate threads...

That said, a portal is a cooperative environment. Portlets typically are not islands, they usually are combined visually and interact with each other. Therefore they will also typically need to share entities, DAO layers, etc. If you do not use SB, you risk using many more resources than necessary and have to be concerned with deadlocks and/or update collisions...

Say, for example, you create 5 portlets that you are going to drop onto a single Liferay page. These 5 portlets are related to your bookstore business, and although they are related you have them deployed as 5 separate plugin projects. Each one is going to have to look at your inventory, your customer database, purchase history, etc. in some form or another, either combined or separately.

Now with this scenario, if you're going to use JDBC that means since the 5 projects are deployed separately, they must each have a database connection (or pool of connections) so they can retrieve the data they need to display. This is where the resource consumption increases, because they cannot share the connection pool. Deadlocks and update collisions come into play when you have multiple updators to the data; two portlets updating the same table/data at the same time (likely since the portal page would have all portlets synced up on the same information), each is trying to update the same info at the same time and could be a potential point of collision and/or deadlock.

Now if instead you did things the Liferay way using Service Builder, all of these issues go away. SB code can be used on all 5 of the portlets, so there's no code duplication. The service providing portlet (the one with the service.xml) is the only one with the database connection (pool), so your resource usage is manageable. With only one piece doing the adds/updates/deletes, your collisions and deadlocks are greatly reduced. Finally, since SB enables EhCache (or whatever caching mechanism you're using) for entities, calls to retrieve data might not have to go to the database at all.

SB has it's problems, certainly, but the benefits you garner from using SB from the beginning make it well worth it.

That's a really great explanation of the benefits of our ServiceBuilder. Thanks David.

No problem. I try to encourage everyone coming to Liferay to use SB. It is lacking some functionality I'd really like to have personally (i.e. a non-DB entity so I can define the entity, get the whole XxxLocalServiceImpl and XxxServiceImpl support for defining methods, yet still have the whole CLP mechanism so it is available in other plugins). But in the end you just can't beat the functionality of being able to centralize your data services yet have the code accessible both to local plugins and web services too!

The difficulty, of course, is convincing folks it's the way to go. When you come from a servlet-type framework where you have to manage your own connections, generate your own hibernate framework, and wire it all up with spring, you automatically start down the same path just replacing "servlet" with "portlet". Unfortunately the impact of that decision is not apparent until you get a lot farther down the development cycle, then it becomes clear that the old way just doesn't work with the new way...