uPortal Content Management Integration

Owned by Jen Bourey
Last updated: Jun 09, 2010Version comment
4 min read

Internal vs. External

Internal CMS

The simplest CMS integration might involve embedding a JCR store into the portal and providing a simple WYSIWYG portlet for editing operations.

Jasig already has an incubating simple WYSIWYG CMS portlet which is capable of interacting with a JSR-170 content repository such as Jackrabbit. The simplest CMS integration might be to embed a JCR store into the portal, and then use this portlet as the front-end for editing operations.

This approach might be particularly compelling when combined with the delegated portlet management capabilities present in uPortal 3.2 and above. uPortal's new portlet management tools allow sufficiently-privileged users to create new portlets, then walk them through a content approval/publishing/expiration workflow. Permissions for each step may be delegated to groups of users by portlet category. Combined with a simple WYSIWYG portlet, these new management capabilities could provide powerful workflow control of content creation and editing that might meet the needs of most institutions.

In the approach described above, Jasig would likely clean up the existing portlet and modify it to present the current editing interface as the CONFIG mode. Jasig would also need to integrate a JCR store into uPortal and address import/export needs for the portlet.

External CMS

Contents are managed by an independant application (the web CMS).

External  integration could assume that the web-CMS supports CMIS (or proprietary similar) protocol able to browse sitemap or content repository.

Re-usable Portlet Publishing Type

To expedite the publishing of content within the portal itself, it might be helpful to include a content authoring portlet type in uPortal meeting the following use cases:

1. A sufficiently-permissioned administrator would like to create a new portlet configuration with brand new content.
2. An administrator would like to create a new portlet configuration pointing to an already-existing content item in the configured CMS.
3. An administrator would like to edit an already-existing content item in the CMS through the portlet publishing type's configuration interface, either as a new portlet or by editing an existing portlet registration.

The new Jasig Simple Content Portlet might provide a useful starting point for such a publishing type. This portlet allows administrative users to display HTML content to end users via a WYSIWYG interface. While HTML content is currently persisted via the portlet preferences, an alternate persistence service could be created to persist data to a CMS via CMIS. This enhanced portlet would need to offer administrative users the ability to select existing content items, as well as potentially fork/duplicate items as they are edited.

Such a portlet should enable institutions to configure uPortal to use an external third-party CMS, provided that the CMS supports the CMIS standard. uPortal might also consider embedding a JCR store such as JackRabbit within the portal and exposing a CMIS interface via the JCR-CMIS connector project. This strategy would enable institutions to use the CMS portlet without needing to adopt and install a third-party CMS server.

CMS Administration Portlet

The publishing type described above would allow administrators to easily create portal content and to administer content for already-configured portlets. It would not allow administrators to easily edit CMS documents that were not associated with a portlet or allow institutions to manage non-portal CMS content through the portal. For example, some institutions have expressed a desire to use the portal to administer CMS content that might later be displayed in some other, more static institution website.

To meet the above use cases, and to generally provide more powerful CMS interactions, it would be desirable to offer a CMS Administration Portlet. Such a portlet might provide the following features:

  • List and view existing CMS content
  • Edit, delete, and otherwise administer existing content
  • Create new content not to be immediately associated with a portlet registration

(still need to integrate this content)

A Contributer/administrator would add content in uPortal then select a Portlet dedicated to CMS content.

Then a widget should appear (preferably during the "add content" process) displaying one or many sitemap of external CMS. This widget would use CMIS requests to browse remote Web-CMS pages. Apache Chemistry project provides Java implementations of CMIS and may be used to develop such a widget.

 


Known Web-CMS/uPortal integrations

One known Drupal-uPortal integration uses Drupal to both create and manage content that will later be displayed in uPortal. A custom portlet demonstrated at the 2009 Jasig Unconferenceallows portal administrators to browse and select Drupal content from the portal. In this system, Drupal content is offered to the portal in XML format.

Another Ametys-uPortal integration has more or less the same approach. Ametys is used to create and manage content, and a XML-XSLT portlet is used to display content to uPortal user. Ametys content is offered to the portal in XML-Docbook format.

 

External CMS Case Studies

  • UCI

CMS in other portals

Liferay includes an internal CMS which offers workflow capabilities, as well as some structure/template features somewhat reminiscent of Jasig's HyperContent project. Liferay's implementation also offers the ability to push content from a development environment to a production server via a administrative user interface that makes use of web service calls.