As I promised a few weeks ago, in this post I'll share my thoughts about "Liferay Beginner's Guide" book. As with earlier reviews, don't expect any judgments, recommendations or generalizations. Those are to be made by you. I'll only concentrate on what I found interesting (or boring) and worth mentioning (for one reason or another). So let me try to summarize over 350 pages in a few lines.
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.
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:
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:
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.
A few weeks ago I was asked by Packt publishing to review the new Liferay Portal 6 Enterprise Intranets book. Going through over 650 pages took me some time but finally I'm ready to share my thought about it.
By now you are probably scanning the text for something like "In general this is ____ book". Don't bother, I'm not going to generalize in this post. In fact, what you put in place of ____ depends on who you are, what is your Liferay background, and what you expect to learn.
Don't know about you but I can't imagine debugging enterprise class applications without having "tail -f /path/to/log.file" running in dedicated console window. During development and testing phases (assuming work is done "in house") there is usually no problem with this approach as the whole team have access to servers' log files. This is not always the case with staging and production environments though. These days a lot of companies execute strong security policies which sometimes means that application is only accessible via HTTP. In such case, depending on how you SLA looks like, "log files provided on demand via e-mail or FTP" may not be an option.
Facing this kind of problem in recent Liferay based project, made me think about creating a portlet capable of displaying log files. Something like WWW based version of "tail -f". This is how Tailgate was born (for those of you looking for solution here is download page). The rest of this post will concentrate on explaining why it was not "a max 2h of coding" as I thought in the begging.
