Hippo

Yesterday we discussed our development schedule for the upcoming half year. In the next couple of months we will be working on Hippo ECM release 1.0, which contains Hippo CMS 7 and Hippo Repository version 2. Also included in this package will be Hippo Portal release 1 and Hippo DMS release 1. The result will be a complete package for content management in the enterprise. The last two components, Portal and DMS have been anticipated by Hippo for a long period of time already, but have never been released as separate software products. Combined with the fact that the numbering of our current version of the CMS and Repository is out of sync with each other, we decided to add clarity by combining all the different tools into one clear package called Hippo ECM.

Towards a new architecture

Hippo ECM will be focusing on providing the developer with a stable toolkit of open source enterprise content management components. Individual components of the Hippo ECM toolset will be available to developers setting up their own custom-built applications. But combined all components give the developer the power and flexibility of Hippo's XML querying background and a highly flexible and extensible content management user interface.

This extensibility is very important to us. Over the years we have noticed that our core public consists of developers using our components to create their own bespoke applications. And not so accidentally this happens to match perfectly with our own vision on open source: a diverse set of reusable components that allow developers to integrate with and develop upon, while at the same time providing a rich and user-friendly interface to the end user. There is no one CMS that provides a solution to all different users for all their different requirements. And we wouldn't want to claim that we do so. But we can get a long way, by cleanly separating concerns and providing a flexible plug-in architecture. And this is exactly what we are trying to perceive with our new release of Hippo ECM.

Plug-ins

For the very first release of Hippo ECM, we will stick to a very bare CMS system that provides no more than just the very very basic functionalities one can expect from a content management system. Pretty much all functionalities will be implemented as plug-ins that can be loaded into the skeleton system. Also, all different components will be extendable in such a way that developers can take an existing component and add their own functionalities on top of it. Developers will be able to share and co-develop their own components in the Hippo Forge, a community with SVN and communication functionalities for the development of Hippo plugins. On all the different layers in Hippo ECM, a plug-in architecture will be implemented. The user interface will allow widgets to be deployed that communicate with back-end plug-ins that have been added to the Hippo Repository. In this way, custom defined workflow actions can be added on repository level that require specific user input and behavior on the UI level, without having to change anything to the core CMS system. Apache Wicket has proven to be an excellent Web framework to develop component based web applications with full Ajax support, and we'll be happy to use it for our upcoming release.

Workflow

Workflow functionalities are handled from within the Repository solely, and only their presentation part will be handled from within the CMS user interface. When accessed from within a different application than Hippo CMS, the Repository will take into account document state and permissions, so no illegal actions can be undertaken. Where possible, workflow actions will be exposed through the JCR API.

Hippo Portal

For Hippo Portal, extensibility comes naturally since it has been developed as a portlet specification compliant environment (JSR-168). Portlets have been designed to separate presentation from back-end application logic, allowing developers to work together on an aggregated view of several underlaying applications without having to take into account their individual behaviors. We will be working with the JSR-286 group to define the portlet 2.0 specifications. Also, we will work with the Apache Wicket community to improve portlet support from within the Wicket Java Web application framework. Apart from the fact that Wicket is a strong framework for developing portlets, this will also allow running individual CMS components (as Wicket apps) within a larger Portal environment.

Hippo DMS

When it comes to document management, the plug-in architecture adds the possibility of allowing different content sources and workflows to be plugged in. In the future, Hippo Repository should be able to function as a layer on top of several back-end repositories, only referring to objects in an external repository from within its own global index. This allows existing legacy repositories or databases to be kept in place, only adding the need for an indexing trigger to be called whenever a change is performed. The global index will be able to define relationships between -- for example -- Word documents, e-mails, and regular XML content in the repository.

Up next

However, the most interesting part of the new Hippo Repository, and therefor the core of Hippo ECM, will arguably be its built-in faceted navigation support with virtual directory structures. But that's part of the next blog entry!

Stay tuned.

Arjé