Rich Internet Applications Using Backbone.js and Liferay


It’s 2014 and your portal needs to get RICH! It’s no longer enough to have a portal that just works and presents information to your end users from multiple different sources. Today, it’s just as important to have a rich and easy to use interface.

The tooling available for the front-end today is the best it’s ever been, so good that the front-end today can finally become a first class citizen on the web. Traditionally, the backe-end influenced how your application’s front-end gets built, what frameworks get used, how the builds and deployments are performed, and so on. In this article I’m going to show you how Veriday super-charged our Liferay portal development practices by using Backbone.js and other front-end tooling.

A little bit of history

Our engineering team at Veriday has been using Liferay for over 7 years now. We have seen Liferay grow from an up and coming player in the enterprise portal space into a best-in-class technology going head to head and winning against incumbents such as Websphere Portal, Oracle Web Logic and Microsoft Sharepoint. 

Hello Backbone.js

Backbone.js is an extremely lightweight Javascript framework with a RESTful JSON interface based on the model-view-presenter design pattern. Today our engineering team has been exclusively using this framework for over 2 years now because it 1) allows us to iterate faster on the front-end and 2) is fairly flexible and integrates well with our web services based architecture.

So far we have used Backbone.js in two different ways. We utilize it when we’re building our products such as MapCMS. We also use it when building Liferay portlets. The pattern we use to integrate it with Liferay portlet diverges from Liferay’s portlet development documentation, but being able to diverge from the patterns described in the Liferay documentation allows us to also bring our own experience and lessons learned to the table.

The hybrid JSF/JSP + Backbone.js approach

We refer to the way we decided to integrate Backbone.js into our portlets the “hybrid” approach. The main reason is we still wanted the portal and portlet infrastructure, but at the same time we wanted the flexibility and richness we gain from single page applications. In this approach we build and deploy our portlet projects in the usual standard way, but the portlet just ends up being a shell for the Backbone application. In this method we also gain the advantage of being able to bootstrap the Backbone application without incurring the delay of performing an initial Ajax request to initialize the portlet. This is a very handy way to provide some contextual information to Backbone, for ex. is there a logged in user or who is the logged in user, or what is the current user’s locale preferences?

How do we load Backbone

So you can’t just use Backbone without drinking the rest of the cool-aid. Before we bring Backbone into the picture, we need to present some other libraries that make things more efficient and easier. The first library we need is Require.js for Javascript module loading and dependency management. Require provides the module ‘import’ mechanism from other programming languages like Java or C for example.

    //The name of this module

    //The array of dependencies

    //The function to execute when all dependencies have loaded. The
    //arguments to this function are the array of dependencies mentioned
    function (Employee) {
        function Manager () {
            this.reports = [];

        //This will now work
        Manager.prototype = new Employee();

        //return the Manager constructor function so it can be used by
        //other modules.
        return Manager;

The Require.js example above shows how it is used to define a module which you can then load using require within your portlets:

require(["some/script.js"], function() {
    //This function is called after some/script.js has loaded.

So using the above pattern we can define JavaScript modules, and then load them in asynchronously using Require.js within each portlet’s JSF view or JSP.

What about HTML? Where does that go?

The second part of this puzzle before we get to all the Backbone goodness, is what do we do with our application’s markup? how do we load it? The first thing we decided here is there will absolutely never be any HTML within any JavaScript or event Java code. It’s very important for you to make this decision up front as it will help you avoid a whole lot of headaches as you maintain and enhance your portlets over time.

Now we introduce another library called Underscore.js – this library provides dozens of utility functions that we will need. One of these is the _.template() function.

], function(StoreResultTemplate){
renderStoreResult: function(store){

                var templateHtml = _.template(StoreResultTemplate, {
                        store: store


In the example above we use Require to load a plain simple html file called map-store-result.html, and we use Underscore’s template method to parse the template and populate it with values – ex. a “store”.

<div class="span6">
    Dealer: {{store.getOperatorName()}} <br />
    Phone: {{store.getStorePhone()}} <br />
    Fax: {{store.getStoreFax()}} <br />
    Auto Service: {{store.getStoreAutoService()}}
<div class="span6">

The above HTML snippet is our template code referencing different attributes of a “store”.

Let’s take a look at some Backbone.js already

We now have all the pieces of the puzzle and can get Backbone loaded into a Liferay portlet, we know how to load our modules, and finally  we also know where our actual application markup will live.

Models and Collections

Backbone provides the basis for models and collections that will store your data on the front-end, communicate with your back-end web service endpoints, and provide you with a mechanism to build event-driven front-end applications.


The last piece is the Backbone View which handles all the front-end logic and business rules. View respond to user actions such as clicks, manage models on the front-end and synchronize them with the back-end. A typical view would 1) fetch some models or collections from your back-end, 2) allow the user to update the model and finally 3) send the model to the back-end to get saved all while keeping the actual view in sync with the model.

Event Driven User Interfaces

The key to a successful view pattern is to fully embrace event driven development. One pattern we use, is we introduce a “dummy” model for the client’s state. We then use that model to track and listen to state changes. The end result is a completely event driven. The event-driven approach also allows us to easily re-wire the events and callbacks to create a completely different user experience at a reduced effort.

var DocumentView = Backbone.View.extend({

  events: {
    "dblclick"                : "open",
    "click .icon.doc"         : "select",
    "contextmenu .icon.doc"   : "showMenu",
    "click .show_notes"       : "toggleNotes",
    "click .title .lock"      : "editAccessLevel",
    "mouseover .title .date"  : "showTooltip"

  render: function() {
    return this;

  open: function() {"viewer_url"));

  select: function() {
    this.model.set({selected: true});



The above code sample illustrates how simple it is to define an event-driven view. Furthermore, by simply altering the event callbacks or trigger we can easily  change the user experience in our Liferay application.

Liferay is a powerful platform for deploying your rich applications on to, it is also pretty flexible in how you build your applications so don’t be afraid to diverge from their tutorials and documentations and include your own technologies and frameworks; especially when it comes to your portlet’s front-end.

Liferay Accelerates Mobile Application Development

, , ,

Today, Liferay Inc., a leading open source portal software company announced the release of a Mobile SDK that will ship with Liferay Enterprise Edition 6.2. You can read about all the technical benefits here, but, so what does this mean from a business standpoint? Mobile application development isn’t a new concept and for the most part, major industries, like financial services, have figured out a way to get to market with mobile apps either through the use of partners or through their internal capabilities. So, the process of creating mobile apps already exists. How does this move by Liferay change your world and is this relevant?

It’s quite obvious that investments in mobile technologies are increasing year over year and month over month due to the ubiquity of smartphone and tablet usage. In short, user experience and adoption are driving investments in mobile application development. In fact, mobile internet usage is expected to exceed desktop usage in 2014. With this in mind, overtime, your user base will increasingly expect more than just default mobile views of your application, they’ll start to expect mobile application functionality and much like how you’ll lose business with a terrible looking website, you’ll start losing your users with poor mobile user experiences.

So, what happens now? What happens now with no mobile SDK? In short, redundancy. Building a rich internet application, followed by the implementation of a mobile application across multiple devices can only be streamlined to a point, for example, at the database layer. This redundancy results in higher exponential costs for design, development and testing and much longer development cycles. Not a good combination if you’re striving to create amazing user experiences.

With the mobile SDK and beyond, Liferay will continue to create and add to the plethora of services that can be consumed in a mobile application context. And the more shared services, content & collaboration features available to you when you build your applications, the less redundancy you’ll encounter and the quicker you’ll be able to get to market with a mobile version of your applications.

This is an extremely positive announcement from Liferay and aligns very closely to our lean development principles. For us and our customers, it means we can extend the benefits of our development practices to mobile and accelerate the release of those applications even faster and most cost effectively by using Liferay as a central application hub.

The Importance of Software Configuration Management for Portal Projects

, ,
Many enterprise organizations treat large scale portal projects like regular application development projects. This potentially leads to many downstream negative impacts affecting the maintainability and stability of a portal environment. A common pitfall that many organizations fall victim to, is the lack of the proper software configuration management (SCM) processes for their portal projects and on going support models. Much of this is due to the perception that the skill sets required for a portal implementation are the same skill sets their current non-portal application implementation teams’ possess, leading to higher downstream costs.
So how can organizations stop themselves from over spending on future maintenance and enhancement costs? Well, aside from replacing your traditional application development team with an expert portal team, there is a rather small investment that can be made up front to help with the transition. Our team’s are strong believers in the proper creation of software configuration processes and practices but let’s not go overboard, there are other factors that play into the successful deployment and maintainability of a portal such as portal governance, but proper software configuration management is most certainly a key success factor.
You may be asking yourself why it’s important to consider the up front investment of the creation of proper SCM processes and when exactly should these processes be created. Typically, once the implementation of a portal project begins, there is a rather substantial amount of time spent configuring the infrastructure that is going to be used to support the portal environment from development, to test, to staging, to production. We strongly recommend that the creation of SCM processes occur as a parallel activity. This provides you with three benefits:
  1. It will help accelerate the return on investment of your portal investment and don’t forget the downstream risk and cost mitigation as a result of the creation of these processes.
  2. By doing these activities in parallel, it will reduce design gaps between the environment configuration and SCM processes. In one of our recent customer scenarios, they had set up their environment prior to establishing SCM standards and began development. When it came time to deploy the solution, they came to the sudden realization that their environment did not match their deployment methodology. This directly impacted the application’s performance and at times rendered the application unusable.
  3. Assuming you are using subject matter experts (SME), you can blend your current environment and software teams with the SMEs. This will help with knowledge transfer and will also help give the SMEs the proper eyes on both the organizational and technical environments within your organization.

What is Software Configuration Management?

So, we’ve established the benefits of why SCM and why create SCM standards early. But what is it? The act of creating SCM standards can be grouped into two primary activities; Release Management and Code Promotion, and the Creation of a High Level Infrastructure Architecture.
Release management and code promotion focuses on code deployment and testing, auditing requirements, business processes and, code and configuration release (note that this is specific to portal).
High level infrastructure architecture focuses on answering questions like:
  1. What database will be used for this portal application?
  2. How will we be performing user access and authentication?
  3. What kind of network infrastructure will be configured?
  4. How will we handle disaster recovery?
Ok, I’m convinced, but what kind of people do I need?
This blog post would not be complete if we did not tell you what kind of team would be required for this crucial step in your portal initiative. We’ve typically provided customers with a team of three. Not all of them would be full time and the time spent would be highly dependent on the complexity of your organizational and technical environment. Here are the profiles of those individuals all of whom should have multiple years of experience with an enterprise portal:
  • Software Architect
  • Knowledgeable and experience in portal implementations
  • Enterprise application design and development experience
  • Portal experience
  • Software Developer
  • Experience working on structured enterprise application development projects
  • Enterprise Portal experience
  • Experience working on enterprise development teams with regimented code and configuration release management processes
  • Integration Architect
  • Experience in network infrastructure
  • Experience with server configuration
  • Experience with setting up enterprise architecture, E.g. Failover, load balancing, etc..
Let’s recap.
  1. Creating proper SCM standards and processes early in your portal project is strategic and can provide you with downstream risk and cost mitigation
  2. This activity should be performed in parallel with the configuration of your technical portal environment to accelerate the ROI of your portal investment
  3. The team performing this task should be subject matter experts and should be blended with your existing non-portal application team to transfer knowledge around best practices and to gain experience with a portal project

Ant Colonies Solve User Interface Challenges


I just read a great article on Embracing Complexity by the Harvard Business Review and I got a crazy idea about using the same “ant colony” metaphor to breakdown user interface design and architecture.

There is a lot to learn from an ant colony and these lessons can be applied to many complex problems as the article describes. It is difficult to understand how an ant colony works if you just look at the individual ants. Just like in a complex system, you can’t fully understand it by simply looking at the individual components.

A great lesson from these ant colonies is that ants don’t get the “global system” however their local interactions results in this complex system; the ant colony. Nature is full of these complex & adaptive systems that just work; no leadership; no congress; no committee to make decisions. However us humans like to think of things as “cause and effect” and in software engineering this translates to “sequential programming”. We look at the systems we are trying to build as a chain of steps; doStep1(); doStep2(); etc. We need to break out of this cause & effect paradigm. We can take this a step higher and even compare this to the most popular software engineering process; the waterfall.

We can look at application user interfaces as complex systems that is broken down into individual components that communicate together in the “local” context i.e. the current user view. The whole is greater than the sum of the parts. These applications we are building are really event-driven just like any system that exists in nature. Decisions lead to cascading events. A user clicks on a button, some components choose to respond to that event. Or the server emits some signal that some other components would choose to respond to.

So how do you take these lessons from an ant colony and apply it on your next UI project? Think events, stop thinking functions.

  1. Break your UI into small components and widgets with related functionality
  2. Use the publish/subscribe mechanism within your framework. You can have a look at my post about Dojo’s Publish and Subscribe.
  3. Design your components to communicate with each other using events. Widgets communicate with other widgets around them i.e. local communication
Embrace complexity in your UI projects – it will only get more complex for you as your users demand richer interactions.