Using viewlets (and views) in third-party products

[Martin Aspeli]

Hi George,

> (1) Right now, the viewlets managed by a viewlet manager, are set globally. 
> Does Zope support local registration?  

Yes - viewlets are just adapters. But the ZCML directive then doesn't 
work, so you need a new (probably GS-based) syntax. I'm not sure how 
that'd support some of the class-generating voodoo that the ZCML 
directive does.

> It seems that this would solve a lot
> of problems.
> 
> (2) Second, if a viewet is managed by a viewlet manager, but not explicitly
> ordered in viewlets.xml, it still shows up.

Yep. The whole 'viewlets.xml' is a Ploneism, there to give us control 
over ordering, mainly, and the ability to selectively hide things.

>  Do Zope and Plone support
> making viewlets hidden by default instead of visible by default?

We could, but I'm convinced this is sensible - once we made the policy 
switch, a lot of things would disappear, and we'd have to ensure 
everyone used a GS XML file.

> It seems
> that this too would solve a lot of problems.  For instance, if I added a new
> viewlet "example.credits" managed by "plone.footer" globally, every site
> with every portal skin/theme interface gets it and it shows up
> automatically.  

There is some performance penalty for finding-but-not-showing a viewlet 
like this too, but I'm not sure it's large.

> But if instead I had to take a second step of declaring it
> in viewlets.xml to be shown by plone.footer for a local portal skin, this
> wouldn't be a problem.  

True.

> This is parallel to how even though lots of skins
> directories are registered on the file system, they have to be explicitly
> added to each Plone site's portal_skins directory.

Also true.

> (3) If not, here is my understanding of what the best practice is for a
> small, third-party product that adds, overrides, etc. a viewlet -- with the
> assumption that this third-party product wants to be reusable by other theme
> products or "site configuration" products:
> 
> * Link the viewlet with an IThemeSpecific interface, but not a skin name

Well - any interface; that particular naming convention makes most sense 
in theme products.

> * Inside each separate theme product or site configuration product,
> associate that IThemeSpecific with each portal skin name we want the viewlet
> to be added to. It might just be a new custom skin with name "MySkin", or it
> could be the default "Plone Default," or both, or more.

*shrug* - I suspect a lot (most?) third party products are theme 
agnostic. The idea that we associated CMF skin layers with a particular 
theme now is more a consequence of the fact that CMF won't let you do it 
any other way (there are no "global" layers).

> * But most important, the small third-party product should neither: (1)
> leave off IThemeSpecific, because then every site will get the new viewlet;

True, unless that's what you want. ;-)

> (2) associate IThemeSpecific with a specific skin name, because this makes
> it hard to integrate with other products with unknown skin names.

Well, I don't know if associating it with "Plone Default" would work 
either. I didn't design plone.theme to have more than one marker 
interface per theme name: if it works, it's by accident. :)

> * If the viewlet is being defined *in* the main theme product or site
> product, though, then it's okay to associate IThemeSpecific with a skin
> name, because it's not designed to be re-used by other products.

Yes.

> Does this sound right?

Your understanding here is right, but I think what we really want is the 
hidden option D:

  - We create a new package (e.g. plone.browserlayer) that does 
something similar to plone.theme now but lets third party product 
authors register a particular layer when the product is installed. It's 
not associated with a skin name, but the traversal hook that applies it 
to the request (like plone.theme does by looking up the utility named 
after the current skin) looks for "installed" themes. That basically 
suggests some GenericSetup syntax to register a new layer like this.

Martin

-- 
Acquisition is a jealous mistress