[Grok-dev] Re: layers and skins

Maurits van Rees m.van.rees at zestsoftware.nl
Fri Apr 20 17:14:57 EDT 2007

Martijn Faassen, on 2007-04-20:
> You can have multiple skins for a single layer, I think? Not very common 
> of course, but what will be common is a single layer showing up in 
> multiple skins indirectly through layer inheritance.

I wonder if the following use case for layers and skins makes sense.
I write this partly to check if I am understanding this discussion
correctly and partly to contribute a thought of how someone like me
might expect layers and skins to work.

Let's take a concrete example, GrokChess:


Nothing is done with users yet and probably nothing is going to happen
there any time soon.  But for the sake of argument let's say I have
the following idea:

- anonymous visitors can view the chess board and the names of the

- The two players themselves can do moves.

- A referee can start the game over or undo or redo a move.

One way would be to put everything in one view and template and
use conditions in the template (or the view) to only display those
parts of the page that the current user is allowed to see.  But there
is no role for layers and skins there, so that is no fun.  That would
be a five minute argument and I am going for the full half hour. ;-)

Another way is to split those possibilities up into several
templates/views and use layers or skins.  The wishes are:

- Everyone is shown the base view.

- The two logged in players have an extra tab that leads to the edit
  view where they can do moves.  It probably does not make sense for
  them to see the base view tab at all, but let's say that they have
  that option anyway.

- The referee has both tabs and also an extra referee tab.

So we create three views: BaseView, EditView and RefereeView.  Let's
register them in three different layers.  Or associate them with that
layer, whatever you want to call it.

- BaseView:    associated with anonymous_layer

- EditView:    associated with player_layer

- RefereeView: associated with referee_layer

All three layers probably have more views in them.  For example, the
player_layer might have a form where the player can change his name,
upload a photo and write down his favorite chess joke.

Now to the skins.  We define three skins: DefaultSkin, MemberSkin and
ManagerSkin.  Hm, let's first quote Martijn again before we continue:

> grok.layer associates something with a layer. a view can be associated 
> with a layer. a skin can also be associated with a layer. Typically you 
> have way more views associated with a layer than skins of course, but 
> the direction of association is the same. Since grok.layer can be used 
> on module-level, sometimes you don't even have to mention the layer the 
> skin is working for explicitly.

I am not sure if it matters whether a skin is associated with a layer
or the other way around.  I am inclined to think: a skin contains
layers and a layer contains views.  But that might be too rigid
thinking.  For one thing, like you say: a layer can be in (or
associated with) more than one skin.

If grok.layer already exists for associating views with layers, then I
guess it makes sense to use that for associating skins with layers

Well, back to the example.  We have three layers and three skins.  How
do they fit together?

- DefaultSkin: is associated with the anonymous_layer

- MemberSkin:  is associated with the anonymous_layer and player_layer

- ManagerSkin: is associated with the anonymous_layer, player_layer
  and referee_layer

Some other part of Grok would make sure that anonymous visitors are
shown the site with the DefaultSkin, the two players get the
MemberSkin and the referee gets the ManagerSkin.

A player can now see the EditView (maybe he is redirected to that
automatically) and the BaseView.  If he tries to go to the RefereeView
(probably by manually changing the address in his browser) he gets a
404 Not Found error as Grok cannot find that view in his skin.

Is this way of making use of layers and skins making sense?

Hm, one more thought: who is responsible for associating a skin with a
layer?  And who should create skins?  In other words: what should Grok
do and what should GrokChess (or other third party products) do?

I can imagine that a standard Grok instance provides a
Default/Anonymous Skin, a Member Skin and a Manager Skin.  Or if that
separation does not make sense, then think of a Default Skin and a
StoneAge Skin.  Hm, WoollyMammothSkin maybe? ;-) 

But maybe StoneAge or perhaps simply Blue Skin give me more of a
*theme* feeling, whereas I now think that skins are more about which
*functionality* (provided by layers) is available to the user of that
skin.  It is a bit like the Plone Default versus the Plone Tableless
skin, where the only difference probably is that the order of the
layers is different.  That is probably a good reason not to use the
term 'theme' for skins after all.

Okay, I am getting sidetracked here. :)

So Grok defines skins.  Then in my GrokChess product I define those
layers: anonymous, player and referee layer.  If GrokChess stops
there, then I guess nothing much happens, as the layers are not made
available in a skin so nobody can see anything.  Or probably by
default they end up associated with the Default Skin.  So GrokChess
needs to do something with those layers.  I guess for me that sounds
like I want to associate a layer with one or more skins, not the other
way around.  That could be my CMFPlone habits kicking in though. :)

So I expect to be doing something like:


Not that this method exists, but you get the idea.

I probably would not mind if instead I had to do something like:

from grok.skins import DefaultSkin, MemberSkin

Anyway, I would expect the following:

- Grok defines some standard skins.

- GrokChess defines some layers.

- GrokChess associates layers and skins.

- If GrokChess really wants, it could add its own skin, but this is
  frowned upon.

Does this make sense or do I need a brain wash? ;-)


Maurits van Rees | http://maurits.vanrees.org/ [NL]
            Work | http://zestsoftware.nl/
"Do not worry about your difficulties in computers,
 I can assure you mine are still greater."

More information about the Grok-dev mailing list