[Grok-dev] Re: layers and skins

[Martijn Faassen]

Hey,

[snip]
> 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:

class IAnonymousLayer(Interface):
    pass

class IMemberLayer(IAnonymousLayer):
    pass

class IManagerLayer(IMemberLayer):
    pass

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 
entry, etc).

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

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

> 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:
> 
> anonymous_layer.associateWithSkin('DefaultSkin')
> player_layer.associateWithSkin('DefaultSkin')
> player_layer.associateWithSkin('MemberSkin')

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:

class MySkin(grok.Skin):
    grok.layer(IMyLayer)
    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.

[snip]
> 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".

Regards,

Martijn