[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?
Regards,
Martijn
More information about the Grok-dev
mailing list