[Grok-dev] Re: layers and skins

[Martijn Faassen]

Philipp von Weitershausen wrote:
[snip]

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

Let's step back a bit. Let's imagine someone coming to Grok with no 
prior experience with CMF or Zope 3.

Saying, yeah, this is called a grok.Theme which consists of layers but 
this actually creates something we call a skin that shows up in the URL 
as ++skin++, which is this somewhat subtle concept, etc, doesn't strike 
me as the best story we can tell.

I'd rather have a simpler story, either seeing ++theme++ in the URL, or 
++skin++ in the URL, and the same in code.

Now we go to ++skin++ versus ++theme++. I like the word 'skin' better. 
This is because I can imagine web applications where you have an edit 
skin and a view skin. Or a web application where you have an admin skin. 
In fact, that web application will be grok. The word 'theme' doesn't 
work here, I think: you don't have an admin theme or an edit theme. 
Skinning a web site is about more than having alternative layouts of 
things; it can be about having entirely different UIs with different use 
cases.

I don't think CMF developers are very important in this discussion. CMF 
developers may or may not pick up Grok, and if they do, they need to 
learn new concepts all over the map, from views to skins.

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

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.

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

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.

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.

Regards,

Martijn