[Grok-dev] Re: layers and skins
kevin at mcweekly.com
Thu Apr 19 17:40:38 EDT 2007
So, regardless of the final outcome of the names, it seems there is a
concensus on the mechanics of how it works.
Based on a merger of Martijn and Philipps proposals.
grok.name('myskin') # defaults to this
+0 grok.Theme, the word it's not widely used (although that might be a
+1 grok.Skin, this feels better to me even if it's not literally correct
-1 grok.implements, although it sounds good on the tongue, it appears to
warp the real meaning too much
+1 grok.layer, I don't think there's a real negative to this
+0 ILayer vs Layer, you say Tomato I say ITomato, also grok hides
implementation details all the time and zope3 is very inconsistent about
Philipp von Weitershausen wrote:
> 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
>> 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.
More information about the Grok-dev