#205: Flexibility Associating Portlet Types and Portlet Managers

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.

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_

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>

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

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.

Code completed!