Pluto 1.1 Integration

Information on this page pertains to the uPortal 3 effort currently underway. This documentation does not apply to any version of uPortal 2 or the exploratory portal code archived in the SVN sandbox. For more information on this effort please read the uPortal 3 Development Documentation

This page is gathering information about the tasks involved with integrating Pluto 1.1 and uPortal

uPortal Integration Points

  • ChannelManager
    • Needs to know what portlets are deployed to the container
  • Portlet Adapter
    • Needs access to Pluto PortletContainer to do admin/action/rendering calls

New uPortal functionality

  • One PortalControlStructures object per rendering channel
  • IChannel Extensions
    • IActionChannel that can be targeted with an action which is executed before the rendering pipeline starts
    • ILayoutAwareChannel that knows about its current layout state (needed to ensure WindowState/PortletMode sync)
    • IResetableChannel that provides CError a better way to retry/restart portlets. Allow the portlet adapter to use PortletContainer.doAdmin to clear the portlet's session.
  • The portlet adapter should provide access to the ChannelRuntimeData as a request attribute
  • URL Processing APIs early on in UserInstance.renderState, these APIs would be similar to the uP3 request handling.
    • There is a rough diagram of the uPortal Rendering Pipeline in which the UPFile parsring will be moved up to the top
    • In that diagram the URL/request handling would happen as the very first action in the pipeline.

Development Tasks

  • Switch to Pluto 1.1 deployer in EAR

Features Required by uPortal

  • Portlet Session Management
    • For error channel to reset a portlet
    • To expire the sessions when a user logs out
  • Inject publish time portlet preferences

Terminology

  • Pluto Terms
    • PortletContainer - The main runtime interface for executing portlets. This would likely only be accessed by the portlet adapter channel
    • Object Model
      • deployment - (Deployment Descriptor/DD) - The naming of objects that represent data parsed from a Portlet application's web.xml and portlet.xml api
      • window - (PortletWindow) - The object that describes a portlet that can be rendered. The uPortal portlet adapter would pass a PortletWindow implementation to the PortletContainer when calling the portlet
  • uPortal Terms
    • Portlet Adapter - A special IChannel (along with several other interfaces) that wraps the Pluto PortletContainer. This channel takes care of mapping channel API calls to portlet API calls. There will be a specific IPortletAdapterChannel that gets special treatment in the framework for specific functionality.
    • Object Model
      • deployment - equivalent to Pluto's deployment, not sure if any uPortal specific Deployment objects will be created
      • definition - this is what is published in Channel Manager, publish time portlet preferences, overrides title/description, has timeout, etc...
      • entity - this is what is subscribed to, contains runtime portlet preferences
      • window - similar to Pluto's window, tracks parameters, state, mode

Random Musings

Since uPortal doesn't have a similar concept of entities and windows the follow options could be available. When a user subscribes to the channel the channel ID would be used as the portlet's entity ID for storing runtime data. The portlet would then create and manage window objects itself to deal with the possibility of displaying one portlet in multiple ways (on the page, detatched, both at once). Initially there wouldn't need to be a concern for persisting the windows but that option should be in mind when designing the code as the ability to persist window states and other window specific info would be a nice feature eventually.