[Grok-dev] Re: layers and skins
faassen at startifact.com
Mon Apr 23 10:59:53 EDT 2007
> 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
Note that this sort of association would be done differently in Zope 3
(and the proposed Grok solution).
A skin is ever only associated with a single layer directly. Instead,
layers can be in a hierarchy:
Of course you might make it more complicated with multiple inheritance
and such. You could instead have three base layers and combine them
different ways for anonymous, member and manager.
A skin is what takes a layer and turns it into something with a name
that can show up in the request (and later on hopefully title, menu
> 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.
Right. Setting a skin in Zope 3 is actually making the request object
provide (as in interfaces) the right layer. You could do that during
traversal. We need to explore ways to spell this in Grok.
> 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?
I think so. If I'm not mistaken it's even possible for the EditView to
replace the BaseView entirely. As long as they have the same name
(grok.name) the one in the more specific layer will show up (the
> 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. :)
Grok isn't like Plone. You could build something like Plone on top of
Grok of course, but Grok itself actually isn't in the business of
providing a default user interface, so Grok won't be providing a skin.
Well, that's not entirely true, as Grok eventually will be providing an
admin interface that will presumably be in its own skin. But this admin
UI is only meant to help developers and sysadmins for fairly low-level
activities (debugging, exploring the app), not for actual users of the
application. It does less than the ZMI in that it doesn't offer
> 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:
This is what part of the discussion was about. We had something like
this, but then I objected that this isn't very much like Grok. Instead
the idea now to go with this:
grok.name('myskin') # actually the default
Since there needs to be only a single layer associated with a skin (the
rest is done through inheritance), this is sufficient. In the future
when we gain a grok.menu(), this could be used to register the skin into
a particular menu as well.
> Anyway, I would expect the following:
> - Grok defines some standard skins.
So far we are not planning for this. I've had some vague idea about
things ending up in a per-package default layer if no explicit layer is
specified, which might imply a default skin, but this needs more
thinking. Maybe it isn't necessary at all.
> - GrokChess defines some layers.
- GrokChess associates layers with each other through inheritance
> - GrokChess associates layers and skins.
Yes, though only a single layer is directly associated with a skin. All
other layers are associated through layer inheritance.
> - If GrokChess really wants, it could add its own skin, but this is
> frowned upon.
No, GrokChess should definitely define its own skins. Eventually
application frameworks may be built on top of Grok that define standard
skins for you to plug into, but that's not part of Grok's mission.
> Does this make sense or do I need a brain wash? ;-)
Some droplets of water were sprinkled on your brain. :)
It was interesting to see more from the perspectives set up by CMF
experience. This is one target audience the tutorial audience needs to
worry about, perhaps in a sidebar saying "please note, this is different
than what you may expect".
More information about the Grok-dev