eXo ECM 2.2 will be released in the coming days. Along with major productivity improvements, such as Drag & Drop, Thumnails and Coverflows, the release will also unveil the eXo Publication Framework. While reading this post, I hope that you will familiarize yourself with that concept and find some ideas for making your eXo projects even more attractive.
The term Publication is commonly referred as the process of making information available to its target audience. Up to now, eXo ECM has provided a single workflow process called publication workflow. This one allowed JCR content to be validated and finally exposed in eXo Portal.
However, publication is sometimes complex. It usually features many facets that require a lot of customization in the default workflow. Those facets can be expressed by :
- What. We have to identify the actual content to be published. This may be a binary document, a structured document, a document folder, a blog entry, a web site. For a given content, if versioning is on, perhaps a specified revision needs to be published only.
- When. Content may be published immediately or at a specified date. An end of publication may be specified. It is also necessary to log the history of each publication action.
- How. This facet tells what channels to leverage when publishing. A content may be enlisted in an Atom feed, sent by email, copied by FTP. In some cases, hard copies may be sent by postal service too.
- Who. Many protagonists may be involved in the publication. They may be in charge of triggering the publication, validating the content, viewing the content or unpublishing the content.
- Where. This represents the location of published content. Typical examples include a content storage (eXo JCR, relational database, NAS), a web page, a production server.
We call any combination of those facets a “publication lifecycle”. To allow developers implementing their own lifecycles, we created the eXo publication framework. It is made pluggable to allow developing publication lifecycles that match tightely the business needs.
In each plugin, the developer will have an opportunity to implement the state machine modelizing the publication. He will also be able to implement the specific user interface displayed when managing the publication. The following is a screenshot showing such an interface. It corresponds to an example provided in eXo ECM :
By default, at the top of the panel are displayed some basic information :
- the name of current document,
- the name of publication lifecycle used to manage that document,
- the name of the current state in the lifecycle.
Then a diagram is shown. It represents the lifecycle model and highlights the current state.
The next part is specific to the lifecycle. The user can select the revision number of a document to be published, its visibility (any user can view it, or only logged-in users) and the state (published, unpublished).
A tab finally allows to display the publication history of the document.
The following similar screenshot shows the UI publication panel corresponding to another lifecycle. This one allows a web content to be published in an eXo WCM page :
When the user wishes to publish a document, he has the ability to choose one publication lifecycle among those available in the platform.
The leitmotiv when designing the eXo Publication Framework was really “flexibility”. Undoubtly you will be able to leverage it in your own projects to meet your particular needs. I’ve already heared about some members of our community who successfully used it in their own business. The specification of the eXo Publication Framework is available at the following address :