[Grok-dev] Re: layers and skins

Martijn Faassen faassen at startifact.com
Fri Apr 20 07:17:13 EDT 2007

Maurits van Rees wrote:
> Martijn Faassen, on 2007-04-19:
>> 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.
> As a Plone add-on developer I may not be very important, but I will
> share a story anyway. ;-)

I didn't mean to imply you're not important. I just meant to say that we 
shouldn't be too worried about breaking the assumptions of a CMF 
developer (or a PHP developer or a TurboGears developer) because Grok 
doesn't aim to follow the design patterns of these systems very much. 
Then again, we *should* be worried about going against the assumptions 
of *all* developers that approach us.

And you as a grok user giving us valuable feedback are naturally 
important to us!

> It may serve as a data point of how
> confusing the word 'skin' can be.
> The summary is: if you say 'skin' I have no idea whether you mean a
> low level layer or a high level theme.  So I am against the word
> 'skin'.

I'll try to describe what I see in these concepts to see whether it gets 
us anywhere.

A skin is a user-visible concept. A layer is a programmatic concept.

A layer is simply a way to group views together. Layers in Zope 3 offer 
advanced ways of grouping including groups inheriting from each other, 
etc, as layers are interfaces. Layers by themselves don't do anything - 
they need a skin to make them work.

A skin is a perspective on the underlying information. An application 
can have one perspective, or more than one.

If there are more than one perspective, the user is aware of these 
perspectives in some way. The user can for instance know they can go to 
the admin user interface of an application, or the edit user interface 
of a CMS, in addition to the public user interface. The name of the skin 
may be visible in the URL. Skins may be listed in some menu somewhere 
that the user can select.

A skin consists of naming information, potential menu information and 
post-processing information, and a layer. All views in that layer are 
going to be in that skin.

> But whatever is decided, good documentation helps here.  And
> at least it helps when a clear distinction is made and documentation,
> python code and templates all use the terms correctly and
> consistently.


[Plone/CMF story]

I think one of the things that distinguishes Zope 3's approach to layers 
and skins compared to CMF is that Zope 3's layers do less. They are just 
a grouping concept and there is no reason to place them in special 
directories. They can be used for overriding UI behavior, but the CMF 
positively invites you to make copies of templates and scripts to do so, 
and Zope 3 does not. Zope 3 layers can form independent hierarchies, 
while CMF layers, as far as I understand, are stacked on top of each 
other in one giant stack.

If you write a Grok application that is intended to be reused as part of 
a larger work, you should place their views in a layer unique that 
application. You could also place it in a skin. When this application is 
used stand-alone, this skin could be used.

The writer of the larger work could then include this layer as part of 
his own layer by inheritance, and then use that new layer as a skin. The 
skin of the smaller work can then be ignored entirely.

> Anyway, if Grok uses the term 'skin', please be very consistent in all
> places.

Good point. I understand Philipp's point about confusing people with the 
word 'skin' a bit better now that I've read your post. Unfortunately so 
far the alternative word 'theme' doesn't work for me.



More information about the Grok-dev mailing list