The Liferay 6.2 CE and EE is now officially out with tons of new features and new look including some long anticipated staging features as well. What are these features?

User interface changes

The very first change someone will see has changed about the staging is the cool new UI. Seamlessly aligned with the general portal UI, the new looks of staging delivers a cleaner more easy to use interface for the content publishers and even provides more information to the users than before.

The information being given to the user consist of how many data is being exported or imported, what is the current progress of the actual process itself, references validation and even more.

There is one thing on the user interface though which might not be obvious on the first glance. From a UX or a front-end designer perspective this is not challening it all, it is more of a matter of approach or philosophy. The content and the applications themselves are now separated into two different sections on purpose. To make this decision we had to sit down and start thinking about what makes staging really the staging, what is the most basic purpose, basically what are the cornerstones and primary concepts of a process like this.

Back to the basics

As the first part of the thinking we had to establish what is the staging? I couldn't get a grasp on a short proper definition so I went ahead and looked up on wikipedia, and I think the following definitions describes our situation too perfectly:

"assemble, test and review new versions of a website before it goes into production" - Wikipedia

In Liferay terms Staging is a content propagation between two distinct groups. Groups are backend representatives for Sites, Organizations, etc. When we are talking about local live the staging site and the live site are on the same Liferay instance, in case of the remote staging these two groups are on different Liferay instances, might be two different phisical machine.

When the staging is turned on with local live the site's group we are turning the staging on for is being duplicated and it will be used as the staging group from now on.

The next step in the thinking process was what data are we staging specifically. What are the portal objects or content or settings we are staging when the staging is turned on for a site.

My personal experience was that these information can be easily mixed up and it is not straightforward and easy to understand. If the staging is turned on for a site, it means that the portlets (applications) placed on a page, meaning their presence on a page and their settings are always staged. If the settings are being changed in the staging group first the publication has to published before it will take effect on the live site. Also if a portlet is being placed on the page, it has to be published in order to show up on the live site's page as well.

The staging of the applications and their settings is not optional however on the other what it optional is really the content. When someone is turning on the staging there is the option to define what content will be staged. The most important thing here is that these two are independent from each other. If the Blogs is not staged it means the content is not staged the portlet still has to be placed on a page and it has to be published before using it.

Setting these guidelines we could re-design the user interface to have separate sections: applications and content.

Although the thinking process has not stopped here, and we have continued thinking about the very foundations of the staging. And this leads us up to the next section.

Introducing the StagedModelDataHandlers

When we have started to think about the staging we have realized that the original portlet data handlers has been become very hard to maintain, they became very big and complex. So the first step we took is that we have introduced the concept iof the staged model and their data handlers. The idea is simple, every entity during the staging - the staged models - should know everything about their references, their dependencies. From staging (and export/import) perspective the staged model data handlers are the definitive location where the given entity's behavior is described.

The StagedModel itself is a marker interface, and it is being detected during the service building process and automatically being added to the entities where applicable.

Given that information the question rises what makes an entity a StagedModel?

Staging relies on a set of information has to be present during the process, and the criteria for being a staged model is exactly this set of information. The entity should have the following properties:

UUID

companyId

createDate

modifiedDate

These information helps the process to identify for example if an entity should be published or not based on the modified date.

The StagedModel has two child interfaces (also markers): StagedGroupedModel and StagedAuditedModel. The criteria for these is to have an additional groupId and userId/userName combination respectively.

Portlet Data Handlers

By introducing the StagedModelDataHandler the existing portlet data handlers role has changed. In the 6.2 these classes are only have the role of querying and coordinating between the StagedModelDataHandlers. The PDHs are now does not utilize any business logic, they are the executors in the process, representing a set of entities, a set of contents.

Process overview

The process of staging in the backend or the process of the export has not changed dramatically. So if someone was familiar with the old staging process, this is going to be familiar as well with a few additions.

Naturally the whole process starts on the user interface and ends up the staged model data handlers serializing the entities into the LAR file. The road although is long until the process produces the actual LAR file, and there are lot to cover during that process.

In my next blogpost I'll examine this process step by step explaining the different stages of it, and hopefully providing insights.

Staging is one of the unique fetaures of the Liferay portal, serving customers to be able to handle their content across the portal. The feature has been around for a while, and was always a subject of improvement. In the upcoming release though staging will receive a major overhaul, based on users' feedbacks, own experiences.

Several things have changed, a completely new architecture has been introduced, with changes how the entities are being exported, and as the portal is currently getting a new design with every commit in the github, the staging UIs and screens had to take their part of the portal UI improvements. And this is just the beginning of the road. It's already clear that the feature holds a great potential, and several cool stuff can be added for later releases.

The UI redesign process for me personally was a great experience, I do not consider myself something who is very keen on UX and UI design in general. Of course I know all the HTML elements, CSS and others but UX is abolutely not my cup of tea. During the staging project I had the opportunity to work with a talented in house UX expert, watch him considering the different aspects of the interface I would never thought of. I can't help it, I'm more of a backend guy, as long as a code piece prints of something on the console I'm fine with it.

With this blogpost my intention is to kick off a series of other posts getting into details of the new fancy staging. Those of you going to one of the Liferay events, there will be staging sessions on the Berlin Devcon, and North America Symposium, bring your questions there, or ask them on the community forums.