[Grok-dev] layers and skins

Martijn Faassen faassen at startifact.com
Thu Apr 19 14:50:23 EDT 2007

Hi there,

Philipp, myself and Kevin Smith have been having a discussion on the 
layer design that was partially on IRC, so I thought I'd write down the 
current state of the design, as I see it, here, so we have a record of 
what's going on. Note that this is biased by my own ideas naturally, so 
if you disagree with anything here, let's have a further discussion:

* 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.

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.

There are alternatives. We could reuse grok.layer to do this, for 
instance. We could also come up with a new directive. Thoughts?



More information about the Grok-dev mailing list