ANN: plone.browserlayer - installable layers for view components that are visible after product install only
optilude at gmx.net
Mon Oct 1 17:25:50 UTC 2007
Florian Schulze-2 wrote:
> On Mon, 24 Sep 2007 01:17:06 +0200, Martin Aspeli
> <optilude at gmx.net> wrote:
>> Enter plone.browserlayer. This lets you register a layer using
>> GenericSetup, i.e. during product installation. A traversal hook similar
>> to the one in plone.theme ensures that it's applied when you traverse
>> into the Plone site.
>> I'd like some feedback on this approach - I think it works pretty well,
>> but there may be other things I haven't thought about. I'd also really
>> appreciate a volunteer to write a quick how-to on this, to save me the
>> trouble. :-)
> I just stumbled over this while looking through commit messages.
> I'm not sure about the actual implications of this yet. Could you give an
> example where this is needed?
You have a third party product. You want it to install a viewlet (or view or
portlet or some other browser component). You don't want Zope to try to
render that viewlet until you've actually installed your product. Your
product is not a theme (in which case plone.theme would've worked for you).
You don't want to install the viewlet and then hide it with
plone.app.viewletmanager (potentially brittle, especially across multiple
> Would it also help to separate parts of
> plone to make them more easily toggleable?
Maybe... I'm not sure it'd make that much difference for Plone core stuff.
> Is plone.theme the analog of a
> CMF skin and plone.browserlayer is the analog of a CMF skin layer? As you
> can guess, I don't see the whole of this yet.
Mmmm, kinda, but not really.
Basically, in Zope 3, you can tie a browser component to zero or one layers.
A layer is just a marker interface on the request. By default, this is
plone.theme lets you register a new browser layer (which almost always
inherits from IDefaultBrowserLayer otherwise all kinds of stuff breaks) that
you can use for theme-specific overrides. plone.theme has a traversal hook
that applies this by looking up the name of the layer from the name of the
current CMF skin in portal_skins. That's a bit hacky, but it works pretty
well and it's isolated so that we can make it more robust in the future if
plone.browserlayer has a local, persistent registry of "installed" layers.
It has a GS syntax to let third party products register interfaces as
layers. Again, it has a traversal hook (which could be consolidated with the
plone.theme one if we moved plone.browserlayer into the core) that applies
all these to the request (by contrast, plone.theme applies only the one
corresponding to the current theme).
So in a way, they are similar, but in other ways they are not. Specifically,
plone.browserlayer layers are not theme-specific, in the way that CMF skin
layers are collated by skin. I'm not sure there's a strong use case for
having them *be* theme specific in fact. Most of the time, a third party
product is not going to know about or care about your theme, and your theme
is going to want to be able to override something from a third party product
(which may not work 100% reliably at the moment, until we consolidate the
two traversal hooks or be more explicit in the ordering of marker
View this message in context: http://www.nabble.com/ANN%3A-plone.browserlayer---installable-layers-for-view-components-that-are-visible-after-product-install-only-tf4506262s20094.html#a12983573
Sent from the Product Developers mailing list archive at Nabble.com.
More information about the Product-Developers