Page Comparison

...

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

...

• 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

...

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

Refer to Portlet Features#PortletMode_Servant
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 from different packages are currently used by the uP2 servant:

• A couple of services such as AuthorizationService, EntityNameFinderService, GroupService, EntityPropertyRegistry from org.jasig.portal.services
• A few types from org.jasig.portal package like IServant, IPermissible, EntityTypes, EntityIdentifier
• Lots of components from org.jasig.portal.security such as IPerson, IAuthorizationPrincipal, IAuthorizationService, IPermission, IPermissionPolicy, IUpdatingPermissionManager