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:
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.
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.