Portlet Administration

This page describes the requirements and ideas for publishing a portlet application and portlet in uPortal 3. It relates to UPT-13

There are actually two parts of this which would likely work the best as two portlets. One for administering portlet applications and another for administering portlets.

General Design

The end user portlets should only be user interfaces to a set of publishing APIs. This will allow other tools, such as a publisher based on XML documents, to be created easily.

Portlet Application Publishing

• uPortal DAOs should provide a list of portlet applications that can be published.
• The user selects a currently deployed portlet application and is provided with mapping options from data provided in the portlet.xml to uPortal 3's support for the features. These mappings will apply to all portlets in the published application.
  • Custom Portlet Modes
  • Custom Window States
  • User Attributes
• What options should be given to a user for deleting a published portlet application
  • If a user deletes a mapping a list of published portlets based on the mapping should be displayed and the user should have the confirm that deleting the mapping will also delete those published portlets.

New Application Workflow Outline

This describes the interaction a portlet UI or XML based publishing tool would have with a set of high level portlet application publishing APIs.

1. Get list of portlet application names (Web-App context names)
2. Get declared PortletModes, WindowStates and User Attributes for a specified portlet application
   • Return this information as a single object
3. Set the mappings for the PortletModes, WindowStates and User Attributes, a unique name must be specified.
   • Specify this information as a single object

Portlet Publishing

• The user selects a published portlet application, a list of portlets in the application is displayed.
• The user selects a portlet from the selected portlet application.
• The following fields should be prompted for from the user, pre-populated from portlet.xml data if available. This data is layered over the portlet.xml data.
  • Name
  • Description
  • Title
  • Short Title
  • Portlet Preferences
    Should allow to change default values of some parameters and control whether they can be further modified during subscription by the user.
• Other information for publishing
  • Groups that can view the portlet (Needs GAP module & Groups Portlet)
  • Categories the portlet is in (Needs GAP module & Groups Portlet)
  • Select PortletModes that the portlet supports that should have buttons to toggle displayed.
  • Select WindowStates that the portlet supports that should have buttons to toggle displayed.

Portlet Subscription

Although this is formally a different JIRA task, two portlets will share most of the screens, and should be developed in close cooperation. The portlet will have to perform the following actions.

• Show portlet categories (filtered according to user permissions)
• Allow user to select portlet by browsing categories/sorting or searching
• Allow user to modify Portlet Preferences (once again, according to permissions)
• Hand over configured Portlet Entity for layout placement

Common modules of the portlet management portlets

The primary feature of our administrative portlet development effort should be extensive reuse of the java and UI pieces. The publish&subscribe portlets provide a perfect ground for testing our ability to do this. There are a number of large workflow pieces that are used several times, and obviously, there will be a considerable number of small UI pieces we should be able to reuse (for quicker development and better consistency). I don't think we've decided on how these modules will be defined/maintained/integrated. Below is a list of major pieces required for portlet management functions. Hopefully we can come up with a strategy based on these examples.

Group selection/Permission definition

With permissions definition UI being considerably enhanced in uP2, it will be quite difficult to replicate all of the features in a newly created portlet. Of course in uP2 this is implemented using servant IChannels, which will force us to mock up uP2 environment for the purposes of rendering these blocks. Depending on what our approach will be for defining portlet modules, we might also have to take care of serialization.
An alternative is to revamp uP2 servant channels into portlets by minimal set of changes (i.e. incorporate serialization, adapt to portlet interface and control structures). This may be easier than dealing with a "black-box" servant code.

Selection from categories

We'll need to select portlets from categories (for subscription). There also should be functionality to search for portlets, and to go through sorted lists of them.
Similar functionality may be used to select the target categories during portlet publishing (which overlaps with GAP module functionality).

Portlet Preferences

Although the view will differ because of permissions, the same module can be used to present UI for modifying/setting portlet preferences during publish and subscribe steps.

Groups Manager Servant refactoring

One of the common reusable components is the Groups Manager Servant that currently extends the uP2 multithreaded channel adapter.
In uP3 the servant needs to be rewritten to support JSR-168. The goal is to preserve the code with the existing business logic as much as possible. Some of the components like permissions from org.jasig.portal.channels.groupsmanager.permissions package could easily be reused without modifications,some of them need to be replaced, for example, ChannelRuntimeData with PortletRequest, ChannelStaticData with PortletContext, etc. The entire logic of CGroupsManager channel has to be rewritten in a portlet application.
The following interfaces and classes are currently used by the uP2 servant:

• A couple of services like AuthorizationService, EntityNameFinderService and GroupService from the package org.jasig.portal.services