Using viewlets (and views) in third-party products

[Martin Aspeli]

Hi guys,

A post on plone-users a couple of days ago alerted us to a "hole" in the 
viewlets story in Plone 3.

Basically, a viewlet is configured instance-globally in configure.zcml. 
It's possible to tie it to a Zope 3 browser 'layer', an interface (which 
is really just a marker interface on the request), so that it's only 
found when that 'layer' is active.

We fixed that for themes, with plone.theme, which lets you register a 
layer for a particular Plone theme (skin). That way, I can have a 
viewlet in my own theme overriding or supplementing ones from standard 
plone, without it showing up on sites not using the theme.

The problem is that if we have a third party product that wants to 
install, say, a tagging viewlet, but only have this show up on sites 
where it's actually installed, then that product can't define a brand 
new theme (since only one theme is active at a time). It *could* of 
course render the viewlet conditionally (if I'm not installed, render 
the viewlet as a blank), but that'd be cumbersome and silly.

I'm proposing to write a small package that people can depend on (using 
egg dependencies, so it'd be automatic, at least for egg-distributed 
packages), that we can push into Plone core either with 3.5 or before, 
if Wichert agrees (the only reason would be developer convenience). It 
would work like this:

  - The third party product author creates a new 'layer' interface

  - Views and viewlets in this product are registered for this 'layer'

  - A GenericSetup XML file is used to register the 'layer' interface 
with some site-local utility (or possibly to register the layer 
interface itself as a local utility, but that'd just be an 
implementation detail)

  - A pre-traversal hook like the one in plone.theme looks up all 
installed layers and applies them to the request. The product author 
wouldn't need to do anything special here.

We'd need a sane way to uninstall as well, but that's about it. Note 
that this is orthogonal to what plone.theme does, although the two could 
be unified. Thus, another option would be to extend plone.theme to 
handle this use case, but then we'd need to either add this to Plone 
3.0.1 or have an optional dependency in a higher version of plone.theme, 
which could cause some confusion (e.g. with plone.recipe.plone, which 
pegs to specific versions).

Does this sound sensible?

Cheers,
Martin

-- 
Acquisition is a jealous mistress