March 2011 Archives

One of the problems with GWT (which is even more noticeable in portal environment) is preserving it's state between page reloads. In a GWT-only application (or single portlet on the page case) one can give user no other option but using only GWT controls to practically avoid page reloads. In most cases however this is not really possible nor wise thing to do. In portlet environments in particular, reloading the page is a very commmon thing to do, giving all portlets a chance to refresh their content after some action has taken place. The thing is, GWT portlets will, by default, render their initial state, which may not be what user expects.      

For example, consider the GWT Chatroom portlet I was using in my previous posts Liferay GWT portlet - how to make it "instanceable" and use GWT RPC and Liferay GWT portlet - replacing GWT-RPC with JSON. Imagine user has entered a chatroom. Then she clicks on some other portlet on the page. The page is reloaded and Chatroom portlet returns to it's initial state. The user will have to enter the room again every time she clicks on another portlet. Let's see how this can be fixed.

This is a continuation of my previous post Liferay GWT portlet - how to make it "instanceable" and use GWT RPC. The approach described there uses Liferay specific functionality called  PortalDelegateServlet. This way one can easily use GWT RPC which somewhat simplifies client-server communication. However if you need to develop a JSR 286 portlet you need a more standard compatible way of doing AJAX calls. For this reason JSR 286 defines serverResource method and this post will show how to refactor the code to replace GWT RPC calls with exchanging JSON messages using serverResource method.

  Almost every portal related RFI/RFP my company has received in the last couple of years contained some requirements about mobile version. Fortunately the times when every device had it's own idea of how web content should be served are gone. Nowdays we can afford to pretty much ignore WML, C-HTML, ... as almost any modern device understands at least XHTML Mobile Profile. However this does not always mean there can be one mobile version for all. Here are some typical requirements:

• make a dedicated version for iPhone (imitate iPhone interface to make it look like native application)
• allow to switch between mobile and desktop version if device is smartphone
• provide alternative input methods if device does not have QWERTY keyboard
• design dedicated version for tablets

I have spent some time thinking about how to address this issues with Liferay Portal. Having some experience with WURFL, Volantice and designing web applications for mobile devices in general, I thought it would be great if I could dynamically change Liferay's look and feel based on device capabilities. And this is how Liferay multi-device extension was born.