[Grok-dev] Re: layers and skins
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
I'll try to describe what I see in these concepts to see whether it gets
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
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
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