Milen Dyankov's blog

If you are following any Liferay related sites, forums, tweets, ..., then for sure you've heard about the new book titled "Liferay Beginner's Guide". The book was released in December 2011 and it is getting a lot more attention that I would ever expect. To be honest I'm kind of surprised there are so many Liferay beginners out there. So I volunteered to review the book hoping to check for myself whether all this buzz is only the result of good marketing strategy or it really provides the beginners with the answers they need.

After my "Pluggable mobile device detection" presentation during Liferay Europe Symposium a lot of people asked about the mobile device emulator I was using. The truth is, it's not a real "emulator" but a simple combination of html page and a Firefox user script. However, it does the trick and for most people seems to be good enough (at least for a start). So, I made a promise to share it and finally found the time to blog about it.

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.  

Every once in a while somebody asks about writing Liferay portlets in GWT. It seems a lot of people are successfully using GWT with Liferay but surprisingly I couldn't find any complete tutorial on the subject. There are a of course tutorials explaining the basics but what they concentrate on, is how to build single-instance and client-side-only portlets. This is good enough to get you started but chances are sooner or later you'll need to place two instances of the same GWT portlet on the same page and/or implement GWT RPC to make use of the Liferay services.

I've reached that point myself sometime ago and unfortunately had to solve the problem myself. Then I wrote sample portlet called gwt-chatrooms-portlet to demonstrate the solution and hopefully save you some time. So here is a step by step tutorial how to create GWT portlet for Liferay 6.0.5 which:

• allows many instances to be placed on the same page
• uses GWT RPC for client-server communication

The last 6 months were extremely busy for me.  A lot had happened in both private and professional aspects. Having that in mind I'm quite happy I manged to deal with completely new experience - being a technical reviewer of "Liferay User Interface Development" - a new book published recently by Packt Publishing. Despite the lack of spare time I was somehow able to read and comment on drafts of 10 chapters covering things like theme development, layout templates, velocity templates, tag libraries, AlloyUI, and much more. Hopefully my comments and opinions ware useful for the authors and help them improve the book. 

As soon as Liferay 6.0.5 was released I decided to adapt my plug-ins to the newest framework version. But as we all know, being determined to do something is not the same as having the time to do it. The good news is, a few days ago I finally quit saying myself "never mind, you'll do it tomorrow" and started getting things done. And now I'm happy to announce that Custom Global Markup, Tailgate and Liferay-UI Taglib Demo are already upgraded to work with Liferay 6.0.5.

Please read my previous posts "Custom global markup portlet" and "Writing Liferay portlet to display a file in a way "tail -f" does" for more information about Custom Global Markup and Tailgate respectively.

Yep, good guess, a Java API to bluga.net webthumb in now available. Making your Java application display website thumbnails is now something really easy to implement. Get your API KEY form bluga.net webthumb, download JWebThumb and start requesting and fetching thumbnails with just a few lines of code.   

• custom size thumbnails
• support for both JPG an PNG
• web services or REST based API
• either creates thumbnail instantly or sends notification when done
• free version 

I guess every Java developer dealing with JAVA/XML serialization/deserialization knows about XStream. I was using it for years until yesterday. What happened yesterday? I found out XStream dos not work out of the box with GAE. Well is's not exactly XStream's fault. A lot of stuff does not work properly with GAE due to its limitations and odd security restrictions. But my hope to quickly find patch/workaround, went away as soon as I realized the problem was reported to XStream over an year ago (http://jira.codehaus.org/browse/XSTR-566) and there is still no good solution. 

This way I was forced to look for alternatives. And I found Simple! Conceptually it's a very similar to XStream. Serialization is really simple to use and revolves around several annotations and a single persister object. I got the impression it's noticeably faster than XStream. It's feature list is quite long (it even claims to be bean version tolerant) but so far I've used the standard stuff like converters, transformers, persister, etc.

However since "Simple"

• does not depend on 3rd party libraries
• is available in central Maven repository
• works out of the box with GAE
• is capable of doing everything XStream is doing  

it's about to become my number one XML serialization/deserialization tool. At least until I discover it's dark sides.