Liferay – Simple Theme Development


Indeed, Liferay has come a long way with its 6.1 version, that fully supports JSF and IceFaces. 🙂 I’m still trying to learn the ropes of it as I aim to have it the standard collaboration tool in our team.

Good Software Application solve problems, but great ones not just solves the problem, but intuitively give users the look and feel of the solvable problem. Applications are usually themed to match of its purpose and value. The twitter application has little bird icons, same as its name and its purpose. Facebook’s simplistic approach made the users visit their site on daily basis because the site’s look and feel is pretty straight forward.

What’s good about Liferay is that all of its components, from themes, portlets to extensions and hooks are all customizable and injectable – injectable meaning that developers can create the components independently and plug it. 🙂 Themes is not an exception:

Download the Liferay Eclipse Plugin

Go to > Help > Eclipse Marketplace > Search for “Liferay”

Once installed, Liferay Tool bar should be displayed.

Note: Install the LiferaySDK and Liferay Portal Instance with the chosen Application Server (I used the lightweight one, Liferay bundled with Tomcat).


Create the Theme on your sketch pad first (plan it) 

Not a sketch, but I did pull out a template from http://www.freecsstemplates.org

A simple bar, content bar and menu / navigation bar should do it. Now to create the actual project and use the theme, go to the next step below.

Create the Theme Project

New > Project > Liferay Portal > Choose Themes

Creating a new project will generate default sources, folders: css, images, js and templates. Now, an important note to this one, these are not the files that you need to edit. I personally use it as my reference.

Re-create these folders under the _diffs directory. This is where the theme development begins.

  • CSS: create a custom.css file on the CSS directory under _diffs
  • VM: Create a portal_normal.vm file under templates of _diffs

Paste the source code of these respectively. portal_normal.vm and custom.css

Deploy

Test, Hit Right Click Project > Liferay > SDK > Deploy Target

Test Locally 

Login > Go To Pages > Site Pages and Choose the Theme! 🙂

Your theme is now ready! 🙂

Download the Project here.

EJB – Architectural Patterns – Message Facade


“How can an EJB client invoke the methods of multiple session or entity beans within one transaction, without the need to block and wait for responses from each bean?”

Asynchronous Behavior – From a J2EE Development standpoint, it is a behavior of a business use case logic can be executed separately from the client itself, e.i without requiring to wait for the execution to be complete. With design consideration of this behavior, we can allow clients to still interact with the user interface with the maximum response times. This is because they don’t need to sit and wait while the use case the initiated finishes. This approach allows a large system to scale, because use cases can be queued and operated on in a batch, transparent to the user, who instantly moves on to the next part of a UI. Portions of the system that actually execute the use cases can also be scaled up and go through system upgrades if backlogs of queued use cases begin to develop, all without changing the quality or availability of service for the clients.

For EJB: We can use message-driven beans to create a fault-tolerant, asynchronous façade. Clients should have access to message-driven beans only, not to entity beans.

I’ve previously posted a basic tutorial on how to create MDBs: https://alvinjayreyes.wordpress.com/2011/07/10/creating-message-driven-beans-total-strangers-can-work/

The advantages of the Message Facade pattern includes:

  • Instant response time/asynchronous communication. When a client sends a JMS message, it is free to continue processing without waiting for the server to complete the use case and respond. A lengthy, complex use case can thus be initiated while control flow instantly returns to the user.
  • Eliminates single points of failure. Using messaging will ensure that your application continues functioning even if the EJB server or some other subsystem it relies upon is down. For example, if the database is down, the MDB’s transaction will not complete, and the reserve seatmessage will remain on the queue and be retried later. If the EJB container is down, the message will again be stored. Such fail-over capabilities would not be possible if we used a synchronous model. Of course if your JMS server is not clustered and it goes down, this still represents a single point of failure, but at least the number of potential show stoppers is reduced.

Disadvantage of the Message Façade pattern includes:

  • Message-driven beans have weakly-typed input parameters. The role of a message-driven bean is to consume JMS messages, all of which appear identical at compile time. This is in contrast to session/entity beans, which leverage Java’s built-in strong typing of the methods and parameters of the remote and local interfaces to catch common errors at compile time. Extra care must be taken by the developer to load a JMS message with the appropriate contents required by its destined MDB. One solution to this problem is to encapsulate all the data from the JMS message into a custom data transfer object, and serialize this object into the JMS Message.

  • Message-driven beans do not have any return values. Since MDB invocations are asynchronous, Message Façade cannot be used for use cases that require a return value after execution. Using Message Façade is thus superficially similar to using Session Façade, in which all session bean methods simply return void. However, it is possible to get a response from a message-driven bean back to the message creator by using JMS as the transport mechanism, please refer to the book Mastering Enterprise Java Beans, Second Edition for a discussion of this mechanism.

  • Message-driven beans do not propagate exceptions back to clients. Unlike session/entity beans, message-driven beans cannot throw application exceptions or RemoteException from any of their methods. MDBs must therefore handle all the exceptions presented in some application-specific format (that is, emailing the user if something went wrong, logging errors to an admin log, and so on).

Key notes:
  • Consider asynchronous behavior when designing J2EE Application Modules.
  • Message Driven Beans is an enterprise ready EJB Component that allow asynchronous processes.
  • Session Facade (Session Beans) can be called from a MDB – thus, regardless if you use any functional design patterns, you can still wrap it around an MDB.
  • MDBs does not propagate exceptions back to clients – MDBs are “fire and forget” methods.
  • MDBs have weekly type input parameters – you usually put all data in a serializable object, pass it through a message for the JMS to be consumed.
I’ll try to create a more complex example of Message Facade pattern using EJB MDB and post it here. 🙂