Using viewlets (and views) in third-party products
optilude at gmx.net
Sun Aug 26 12:59:19 UTC 2007
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
- 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?
Acquisition is a jealous mistress
More information about the Product-Developers