#118: Portlets engine based on PlonePortlets and Viewlets

plone.portlets is a temporary name for the new Zope 3 packages. Suggestions welcome.

PlonePortlets is an existing product in the Collective that has been in production for a number of big deployments. It features a lot of additional functionality over the current infrastructure - including, but not limited to:

• Portlets are Archetypes content types
• Portlets can be displayed per-group, per-user or per-folder
• Drag and drop repositioning of portlets
• Persistent per-user no-reload collapse/expand functionality for portlets
• Built-in caching mechanism with individual policies for each portlet (in progress)
• Ships with a selection of portlets that solves 90% of the common use cases for what people want in portlet listings
• Support for the existing Plone portlet format as well as the new AT-based ones

A Viewlet is a visual component in Zope 3.2 and later. Viewlets are aggregated by viewlet managers and rendered on the page. Various rules can be applied to determine where (in which viewlet manager) a viewlet is rendered and in which contexts it is shown (e.g. only for a specific content type).

plone.portlets will use the viewlet infrastructure in Zope 3 and extend it with more Plone-specific needs.

• The current portlet mechanism is:
• slow
• hard to customize
• hard to integrate with
• and doesn't provide you with much control over the portlets
• We need an improved cache implementation.
• Integration with Zope3 technologies is a must.
• Designe structure with no limitation to 2 slots in mind (left and right)
  

Use Cases for Portlets

Considering two portlets, A and B, where A is assigned to root and B to folder1, and the following portal structure:

root (A)
|
|-folder1 (B)
| |
| |-folder11
| | |
| | |-folder111
| |
| |-folder12
|
|-folder2
|
|-folder3

It should be possible to:

• Have portlet A available at the whole portal.
  
• Have portlet A available at the whole portal except at the root.
  
• Have portlet A available at the whole portal except at the folder1.
  
• Have portlet B available at the folder1 and bellow.
• Have portlet B available only at the folder1.
• Hide portlet B at folder11.
  

Additional use cases (to be assigned from the tool):

• Make portlet C appear to all Images.
• Make portlet D appear to user John.

• Make portlet E appear to users from the Administrators group.

As for Assignment

Portlets can be assigned to:

• context
• option on each portlet
• has option to hide the portlet for the current context [1]
  
• has option to block the inheritance to lower levels [2]
  

• option which affect all the portlets in the current context
  
• has option to block the inheritance from higher levels (blacklisting) [3]
  
• portal type
  
• user
• group
• role
  
• template/view

As for Location

Portlets can be located in arbitrary regions/sections/slots, like for example, left/right column or top/bottom.

Portlet Types

Describing the different types of required portlets:

• Static Text Portlet
• Navigation Portlet
  
• SmartFolder Portlet
• Calendar Portlet
• Login Portlet
• RSS Portlet
• Template Portlet
• Worklist Portlet
• Reference Portlet
  

User Interface Management

• The portlets should be collapsible/expandable.
• The portlets should be orderable (drag and drop in the same slot).
• It should be possible to drag and drop portlets between slots.
• When associating portlets in a context basis, the user interface should indicate the inherited portlets from higher levels.
• The association definition for user/group/portal type/role/template should be done from the tool.
  

Interface Diagram

• IPortletData
  Marker Interface for the Object containing the Portlet Schema
  
• IContentViewlet
  Renders the data from IPortletData with the corresponding method/view/template.
  
• IViewlet
  Baseclass from zope.viewlets package.
  
• IViewletManager
  Representing a Slot.
  
• IPortletFinder
  Marker Interface to provide information about the available Portlets in the Portal.
  
• IPortletFolder
  Marker Interface to handle the storing of the Portlets (persistent Objects)
  

• plone.portlets package (temporary name) that works independently of PlonePortlets
• A set of adapters for making the existing PlonePortlets product compatible with plone.portlets. In fact, PlonePortlets will be used as the initial building block upon which plone.portlets will stand. Code will then be factored down into plone.portlets until it functions as a standalone solution.
• A set of standard portlets
• A migration path from existing plain template portlets to rich plone.portlets
  
• Unit and doc tests are mandatory
• i18n and documentation is also required
  

• On upgrade, PlonePortlets could scan the portal root and all folders for 'left/right_slot' properties and integrate these into the portlet control mechanism as "old portlets".
• The same properties (left_slots and right_slots) defined at individual templates probably can also be migrated. 

The above design has been refactored in part, but the use cases and motivations are still mostly valid.

The bundle contains a pure Zope 3 implementation of plone.portlets, which should be reusable outside Plone, and a Plone integration layer in plone.app.portlets. There is also a branch of CMFPlone with some changes to make the new portlets load, although these are light.

There is

• A standard way of registering new portlet managers (columns)
• A standard way of registering new types of portlets
• A GenericSetup syntax for doing these kinds of registrations
• A rudimentary UI - go to any folder or the plone site root and then append /@@manage-portlets to the end of the URL.
• A ClassicPortlet type is included - this can render existing portlet_foo portlets
• The LoginPortlet has been converted to a new-style portlet, as an example

There are provisions for blacklisting (acquisition-blocking) of portlets and assignment of portlets to users, groups and content types, however there is as of yet no UI for these.

There are no working integration tests at moment at the plone.app level (there is decent test coverage in plone.portlets for all the fundamental behaviour).

• Dorneles Treméa (deo)
• Christof Haemmerle (reco)
• Geir Bækholt (elvix)
• Martn Aspeli (optilude)
  
• <add yourself here> ;-)