#205: Flexibility Associating Portlet Types and Portlet Managers

Contents
  1. Motivation
  2. Proposal
  3. Implementation
  4. Deliverables
  5. Risks
  6. Progress log
by George Lee last modified Jan 21, 2010 07:28 AM

In order to determine if a portlet type can be added to a specific column a.k.a portlet manager, Plone looks up whether that column provides a single interface specified by the portlet type. This proposal allows registering a portlet type for multiple interfaces, in order to give more flexibility where it can be added.

Proposed by
George Lee
Proposal type
Architecture
Assigned to release
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!

Comments (5)

Martijn Pieters Dec 14, 2007 02:00 PM
+1
Andreas Zeidler Dec 14, 2007 02:30 PM
Raphael Ritz Dec 17, 2007 12:41 PM
+1
Tom Lazar Dec 20, 2007 01:07 PM
+1
Danny Bloemendaal Dec 22, 2007 05:43 PM
+1