[Grok-dev] Re: layers and skins

[Philipp von Weitershausen]

Martijn Faassen wrote:
> * layers are subclassed from an interface (like in Zope 3). We are 
> currently still debating whether we call it grok.ILayer and call our own 
> layers IFoo, or whether we say grok.Layer and call our own layers Foo. 
> I'm in favor of using 'I', but we'll see what happens in the end.
> 
> * grok.layer can be used on module or class level to indicate a view is 
> in a layer.
> 
> * to register a layer as a skin/theme, you say:
> 
> class MySkin(grok.Skin):
>     grok.name('myskin') # lowercased class name is actually the default
>     grok.implements(ILayer) # use all views in that layer
> 
> this gets grokked and the skin becomes available. The advantage of this 
> approach is that we can use the regular grok.name() to determine the 
> name in the URL, just like views. We also have the potential in the 
> future to use other directives, like, possibly, grok.title() for display 
> names, and grok.menu() to say something is in a menu.
> 
> Another thing that becomes possible is an optional postprocess() method 
> that gets called for all views in the skin, postprocessing the HTML 
> before output.

In this case we need to ask ourselves what we really mean by "skin". 
This sounds very much like a "theme" to me.

Arguing like a Zope 3 developer, a skin is a marker interface for the 
browser request (hence a skin is also always a layer) that's registered 
as a named utility providing IBrowserSkinType.

We already leave this definition with your suggestion above. In 
principle I have nothing against your suggestion and I find the idea of 
adding theming functionality to that very same class appealing. But then 
we shouldn't call it skin IMO.

CMF developers have a (misled) understanding of what a skin is (they 
usually mean "skin layer"), Zope 3 developers have an understanding of 
what a skin is. Let's not introduce a third meaning if it's conceptually 
different.

I propose to call this thing theme. When a theme gets registered, a skin 
with the same name, composed of the layers that the theme declared, will 
be registered. That also explains why we can use ++skin++foo.

> We obviously haven't fleshed out any of that potential yet, that's 
> another discussion. It's just nice to know it's there.
> 
> Note that the use of 'grok.implements' to indicate layers is potentially 
> misleading. The benefits of using it:
> 
> * grok.implements is already there and we can use the existing 
> zope.interface APIs.
> 
> * grok.implements is also not harmful, as layers can only be marker 
> interfaces. So claiming a skin provides those layers seems relatively 
> harmless and not exactly a lie. You can say you specify here what the 
> request must implement for the layer to be active.

Sure, they're marker interfaces, but for request objects. Unless 
grok.Skin implements the whole IBrowserRequest API (but for what 
reason?), the grok.implements(...) line is a stinking lie.


-- 
http://worldcookery.com -- Professional Zope documentation and training