...
- 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.
- Get list of portlet application names (Web-App context names)
- Get declared PortletModes, WindowStates and User Attributes for a specified portlet application
- Return this information as a single object
- Set the mappings for the PortletModes, WindowStates and User Attributes, a unique name must be specified.
- Specify this information as a single object
| Note | ||
|---|---|---|
| ||
Can a portlet application be published more than once? Does the current object model support this? |
...
- 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
| Note | ||
|---|---|---|
| ||
We currently have both portlet entities and windows user-scoped. I have been thinking that windows should not depend on user IDs directly because they have a dependency on them through entity IDs |
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