Liferay for delivering RIA

Question

Hi Stackoverflow,

I am currently looking into Flex and Liferay for delivering an RIA. We are replacing a rather large existing application built on an internal AJAX/Java library. For this, Flex seems to meet our needs for development but we've had a wrench thrown into the works. We need to integrate with another internal app that's been built on Liferay and JSF.

After looking into Liferay a bit I'm not convinced that it provides any benefits to our existing application since delivery via a portlet doesn't appear to have any inherent benefits other than achieving the integration with the other application. It also appears to have a number of downsides including smooth interaction between the swf and the rest of the page, hooking into Liferay's user management and their general lack of developer oriented documentation.

It seems to me Liferay is a good solution if you need an internal wiki/news/social application, but for delivery of a robust RIA it seems like we're trying to fit a square peg in a round hole.

My question is this: Is Liferay used for delivering full RIA applications or is it a platform that's better suited to delivering smaller apps? Am I missing something about Liferay that makes it a good fit for RIA?

Thanks in advance for any advice!

Answer 1

You can easily get a Flex app to show up in a portal (Liferay or other) but here are some issues you might run into:

1) Typical portal servers hold all of the state - for all of the portlets - on the server. Every interaction causes a page refresh which rerenders everything on the page based on the serverside state. For Flex applications you don’t usually want the state on the server. And you don’t want every interaction reloading the Flex app. Some portals are getting more Ajax’y which solves part of this but there will always be some interactions in HTML portlets or in the portal chrome that cause a page refresh. This means that Flex applications must done some work to persist state beyond a page refresh. A simple way to do this is using LSOs but this requires a lot of extra plumbing code.

2) Inter-Portlet-Communication (in JSR 168 portals) goes through the server based on a page refresh. This also doesn’t work well with Flex apps. JSR 286 is attempting to solve this to support Ajax portlet IPC. Until then making Flex apps work with standard IPC is difficult (but possible).

3) A big part of portals is entitlements, customizations, and preferences. These are all difficult to use and interact with from Flex. In JSR 168 portals there isn’t a standard way of doing this. In JSR 286 there is a standard which makes it easier for Flex to read and update user preferences.

4) With WSRP and other remote portlet technologies portal servers can consume remote portlets and proxy all requests back to the portlet provider. With Flex this is more difficult because portal servers don’t know how to proxy Flex requests (HTTPService, RemoteObject, DataService, etc). In many cases the only solution is to allow the end user’s machine to talk directly to the portal producer server. However many times this causes problems for IT because it means moving another server to the DMZ and potentially bypassing the security constraints imposed by the portal server, SSO server, Security Appliance, etc.

Answer 2

Have a look at www.qooxdoo.org. This is a framework for writing large applications entirely in javascript. It combines excellent GUI control with a java like programming paradigm for javascript and a clever build process for the final application.