[Grok-dev] Re: layers and skins

[Kevin Smith]

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.

class IMonterey(grok.ILayer):
    pass

class Monterey(grok.Theme):
    grok.layer(IMonterey)
    grok.name('myskin') # defaults to this


+0 grok.Theme, the word it's not widely used (although that might be a 
positive)

+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 
this




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