CMS Integration with uPortal

Owned by Chris Myers
Last updated: Sept 29, 2009Version comment

There is a growing need for having content management on campuses, and as a result, an increasing interest on integration with uPortal

One of the products that schools are considering when looking at CMS is Drupal, and are also considering this for their portal, even though it's not a real portal.

  • Primary reason is the ability to distribute content creation
  • One of the competing projects to uPortal is LifeRay, which includes this capability
    • Idea is creating content and then displaying it, vs having a lot of static content
  • Desirable if not critical feature for the campus environment
  • Would need to be easily implemented, but not a required feature

uPortal's primary interest is keeping the framework open and the portlets portable

Liferay's portlets aren't very portable

Many schools already have their own CMS, so aren't really interested in adding this functionality into uPortal

  • Having an API in uPortal that will allow it to be connected to existing CMS's such as SharePoint or Drupal 
  • Standards for CMS products?
    • JSR-170, 283
    • Problems connecting to other JVM's
    • Alfresco, Jackrabbit.
    • Current standards insufficient

However, many other schools haven't proceeded to this yet so would be interested in add-in functionality to uPortal

  • Idea of bundling some capabilities with the portal for organizations that don't already have a CMS, such as
    • as you are browsing the portal, if you have rights to edit specific content, you have an icon that you can click to edit that content
      • content rendered inside the portal (as a portlet, etc.) versus something such as an iFrame where the content is rendered outside of the portal and presented to the end-user
      • showing externally rendered content in the portal versus being able to edit that externally rendered content
    • Integrated authorization, workflows, and permissions
    • Rich media embedding (flash, video, PDF, etc)
    • Creating a new portlet type that is a WYSIWYG editor that saves its content to the database
      • Allowing end users the ability to maintain content within the portlets (eg. the text of certain pages) versus the IT office having to redeploy the portlet after having changed the content.
      • Picking a CMS product to integrate with out of the box to focus on, rather than trying to say that we can integrate with x number of different ones
      • Ability for end users to create their own portlets and then make them available to selected groups, and then pass along the ability for other end-users to edit or maintain the portlets and content.
      • Integrated search capabilities, where the portal itself has an indexing API, so that the portlet can provide certain content to the API to be indexable
      • Indexing restricted content vs public content, controlling who can access this information

Interfacing with external CMS products implemtations

  • single sign-on must be set up
  • passing along the authentication and edit request to the external CMS such as SharePoint
  • interfacing to the workflows of the external CMS just letting them know that they have edits to approve, etc.
  • the reverse of putting the portlets into the external CMS
  • individual portlets per external content vs having an intelligent portlet that is aware of its context
    • portlet must be aware of where it's at, who's viewing it, etc.
  • managing the content inside the CMS and pulling it into the portal?
    • possible problems of interaction between the external content and the portal's CSS, etc.
    • users able to preview the content real-time in the portal without having to publish it
    • then having to separately maintain the portlet itself...
  • Problems of like trying to get Microsoft to build some sort of API interface for other form-based editors, etc to access/edit their content.
  • Ability to publish the external CMS data to XML, etc. for use by the portal

Frying vs Baking (Push vs Pull) idea of CMS

  • pushing content from a db to static files on the filesystem somewhere, regenerating them every time that a change is made

Creating RSS feeds from the created content, and allowing the users to subscribe to them, but containing who can subscribe to certain information and keep other information private

 
Conversation needs to be continued...  Portlets user list or uPortal user lists.  Possibly uPortal Dev list if a group is beginning to work on development.