#205: Flexibility Associating Portlet Types and Portlet Managers

Contents

1. Motivation
2. Proposal
3. Implementation
4. Deliverables
5. Risks
6. Progress log

Proposed by

George Lee

Proposal type

Architecture

Assigned to release

• Plone 3.1

Repository branch

plip205-portlettypes-multiplemanagers

State

completed

Motivation

Currently, Plone determines which portlet types can be added to a portlet manager based on the interfaces that the portlet manager providers. Each portlet type is registered as a persistent named utility, with a variable for_. Either:

• for_ equals None, in which case the portlet type can be added to any portlet column (e.g., left / right / dashboard)
  
• for_ equals a single interface, in which case the portlet type can be added to exactly those portlet columns whose portlet managers provide that interface. For example, a portlet type with for_ equal to IColumn can be added to the left or right Plone columns but not the dashboard; a portlet type with for_ equal to ILeftColumn can be added to the left column.
  

Only allowing for_ to equal a single interface restricts the flexibility of determining where different portlet types can be added. For example, consider the two following scenarios:

• Three portlet managers provide interfaces IColumn1, IColumn2, and IColumn3 respectively, and no other nontrivial interface is provided by the first two portlet managers. Currently, we cannot register a portlet type to be addable to the first two columns but not the third.
  
• We create a portlet manager with interface IBottomColumn to add a section at the bottom of each page on a web site. We want a portlet type to be addable for that column and in the dashboard columns, but nowhere else. Currently, there is no sensible interface we can assign as the portlet type's for_ value.

With this PLIP implemented, we can solve the problems in these scenarios. In the first scenario, we could register a portlet type for IColumn1 and IColumn2; in the second, for IBottomColumn and IDashboard.

Proposal

Allow each registered portlet type to be associated with multiple portlet manager interfaces; that portlet type can be added to a portlet manager providing any of those interfaces.

1. Change the exportimport / GenericSetup import handler for portlets.xml in plone.app.portlets to allow the XML file to pass in multiple dotted interface names for a portlet type's "for_" value, and to set the "for_" value equal to a tuple of interfaces instead of a singleton.
2. Change the export handler to write multiple dotted interface names for "for_"
3. Change the getAddableTypes method in plone/portlets/manager.py, class PortletManager, to see if the portlet manager provides any of the multiple interfaces in for_

Implementation

Example XML from portlets.xml using the new implementation:

Register a portlet type which can be added to exactly those portlet managers that implement IColumn or IDashboard:

<portlet addview="portlets.New" title="Foo" description="Foo" />
  <for interface="plone.app.portlets.interfaces.IColumn" />
  <for interface="plone.app.portlets.interfaces.IDashboard" />
</portlet>

Deliverables

1. The new code!
2. Small migration step for existing Plone 3.0 sites
   
3. Modified or new test coverage
   

Risks

If a Plone site has an existing portlet type registered with a for_ value that is a singleton, this would break the new getAddableTypes implementation. Part of the proposal is to include a small migration to change the for_ value. In addition, getAddablePortletTypes could be written to expect either a tuple or singleton as a further check on backward compatibility, but ideally we would not keep this code for too long.

Update: For backward compatibility, getAddablePortletTypes handles for_ values that are singletons or that equal None. A migration step in CMFPlone migrates for_ values of all IPortletType utilities to lists; None is migrated to []. Plone issues a deprecation warning when getAddablePortletTypes finds a portlet type with an old-style for_ value.

Progress log

Code completed!