Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

...

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

Simple integration : select & display content in uPortal

Simple integration means that contents Contents are managed by contributors in an independant application (the web CMS) with no connection with uPortal (from technical and UI point of view). In this case, contributor has a poor view of what his content will look like when displayed in uPortal.This simple integration assumes

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.

Use case for visitor

Displaying content from a CMS for Portal user is simple. The portlet calls the page previously selected by the contributer, located on the remote CMS. This page is delivered in XML or XHTML format and rendered by the portlet to user.

 


Known Web-CMS/uPortal integrations

...

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.

WYSIWYG integration : create, edit & display content in uPortal

Another CMS integration strategy would be to enable the portal to interact with an external content management system. Such an integration would preferably use the CMIS standard, though integrations could certainly exist that used some sort of product-specific library.

In this integration, contents are managed by contributors in uPortal environment. That means that even if actions call a remote web-CMS, contributor directly sees what content looks like in an environment very similar to uPortal.

Use case for contributor/administrator

A Contributer/administrator would be able to browse uPortal pages and activate content management tools for editable contents. Image Removed

 
When activated, contributor would be offered a bunch of tools dedicated to content management (asset managements, rich text editor, rights management, versionning, workflow...) applicable to its current content selection. In this mode, contributor/admin would be able to browse portal like a regular user, but would see any content, whatever its state in the worklfow (draft, published...).
Image Removed

Selecting an action on contextual menus can induce a pop-up to appear if action is simple (content validation, content deletion...) or the page to releoad and display a new page with other tools if action is more complex (content edition, right management on contents...).

Example of a content beeing edited:
Image Removed
Once edition of content is completed, and author click on save, page would disappear and go back to previous screen.

  Technical issues

This use case induces some technical issues concerning interaction between uPortal and external CMS:

  • Contributor mode is a mode where both uPortal rendering and CMS back-office exist in the same web page:
    • Either this mode is hosted by uPortal (add-on in skin?, core feature?), which should be able to call menus from remote CMS, and associate actions with portlet declared as "content portlet". Such integration would not be generic for all CMS and would need uPortal to adapt to any new CMS.
    • Either this mode is hosted by remote CMS, which should be able to associate its menus and actions with portlet declared as "content portlet" (could be done with HTML/Javascript declarations in "content portlet" rendering). As seen by uPortal, such integration would be generic. On the contrary for CMS, each CMS would have to integrate this mode.
  • Mapping of content location inside uPortal sitemap, and CMS sitemap should be automatic: adding a new editable content in uPortal should offer to admin/contributor a few input fields to enter (Language, Title, Content Type...) and make remote CMS to create the content in its repository. This request could use CMIS protocol, and be generic for any CMS supporting CMIS for write actions.
  • ...?

Use case for visitor

As mapping of contents between CMS storage and portlet location would be automatically managed, the portlet would simply display a remote content (same as "simple integration" scenario):

The portlet (same as used for admin/contributors) should be "rights aware" and display content for visitors by calling remote CMS. The CMS would deliver it to the portlet in XML or XHTML format. The portlet would compute the final rendering in uPortal.

External CMS Case Studies

...