[Grok-dev] Re: layers and skins

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Even a Zope 3 developer won't be much misled if we use the word skin, I 
> think, because I believe there are only a few Zope 3 developers with the 
> detailed techno-historical information that you have. I certainly am 
> somewhat fuzzy about the whole story in Zope 3 myself...

Yeah, the Zope 3 story is fuzzy, no doubt, and I really want to make it 
more straight-forward in Grok.

> So, I'd still propose saying:
> 
> class MySkin(grok.Skin):
>    grok.layer(IMyLayer)
> 
> registers IMyLayer as a skin. That is, IMyLayer can be accessed using a 
> particular name in the URL.

Ah, I get it. So if I had a bunch of layers that I'd like to combine to 
a skin, I'd have to say:

   class IMySkinLayer(IFirstLayer, ISecondLayer, IThirdLayer):
       pass

   class MySkin(grok.Skin):
       grok.layer(IMySkinLayer)

So the MySkin class with its grok.layer directive is just a marker to 
actually register an already existing layer as a skin. Then how is this 
better from

   class IMySkinLayer(IFirstLayer, ISecondLayer, IThirdLayer):
       pass

   grok.register_skin(IMySkinLayer, 'myskin')

?

>>> 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.
> 
> Hm, I'm trying to figure out what ILayer derives from in Zope 3, but I 
> run into the fact that they appear to be deprecated. What does one need 
> to subclass from in a non-deprecated Zope 3.5 world? IBrowserRequest? 
> Just Interface? The deprecation warning doesn't say.

ILayer is not a layer, it's an interface *for* layers that's no longer 
needed (it was an IInterface). Anyway, you can forget about that one.


Layers such as IDefaultBrowserLayer, zope.app.rotterdam.rotterdam, etc. 
all extend IBrowserRequest because that's what they are marker 
interfaces for, a browser request object.

> Anyway, since this is too much of a lie whatever ILayer derives from, I 
> propose we simply reuse grok.layer for saying what layer a skin uses. We 
> say a skin is in a layer by using grok.layer. It's symmetrical with views.

That sounds very confusing to me. We say a "skin is *in* a layer"? 
Usually, skins are composed of multiple layers, so you could say that 
multiple layers are in a skin, not the other way around.

Using grok.layer doesn't seem very symmetrical at all to me.

> The objection to that may be that skins in some ways don't feel 
> symmetrical with views. Then again, there are so many parallels (name, 
> layer, possible entry in a menu) that I think looking for symmetry 
> between views and skins is in fact probably a *good* idea.

I still don't see how skins and views are similar. They're almost 
orthogonal to me. Sure, skins and views *might* happen to need/support 
some similar data points for their registration. So, ok, we'll allow 
those directives that make sense (grok.name and others, once we need 
them) to work on both.


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