[Grok-dev] tightening Grok's layer/skin story

Martijn Faassen faassen at startifact.com
Thu Dec 20 05:34:27 EST 2007


Hi there,

There's currently a discussion on zope3-dev which leads me to think 
about Grok's layer/skin story.

The idea is to have the ability to strictly control what views are 
exposed to the user by using layers and skins. Right now Zope 3 (and 
Grok) is quite liberal in what it exposes. Lots of ZMI skins, in Grok's 
case the admin UI, and so on. By default, Grok's views also are in the 
default layer, which means they're always exposed, no matter what skin.

We should start thinking about a way to gain some good control here, and 
the discussion on Zope3-dev is informative.

I'll quote:

[Robert Ineichen]
 > If we register "absolute_url" in a layer which isn't
 > used in a skin, then this view is not available as
 > traversable view because of the missing layer/named skin
 > configuration.

[Jim Fulton]
 > Which does nothing to "protect" you from components registered for the
 > default layer or for IBrowserRequest.

[Stephan Richter]
 > Yes, because in our code we never ever expose the registrations in the
 > default layer. We consider that layer hostile.  :-)  (Eventually we
 > hope to rid ourselves from even importing any configuration that
 > registers into the browser layer, but the Zope packages need some
 > refactoring to do this in a sane way.)

 > IBrowserRequest is a big problem, since it is the base interface for
 > all layers. I used to scan the ZCML for components registered for
 > IBrowserRequest. I have not done this in a while, but should make it a
 > habit again. I hope that security analysis tools, such as
 > z3c.securitytool will eventually help us identify those problems.

Here we see that Zope 3 features are used in different ways by core 
developers. Jim is questioning the need for layers and skins at all, and 
Stephan thinks they're essential. What Grok needs to do is take some 
best practice and make it the default in Grok. In this case I agree with 
Stephan that skins are useful, so let's look into that.

In Grok's case, we should consider using the default layer a lot less 
and make which skins are exposed explicit. Grok being Grok we should 
still have a default layer things end up in, and a default skin for that 
that exposes tthis default layer, but it shouldn't be Zope 3's base 
layer that all other layers derive from.

There have been some objections to getting rid of the Zope 3 ZMI in the 
past, as it exposes some functionality that is useful and not yet in any 
other replacement UI. I think we should really go through with getting 
rid of it, in the name of purity. Replacement UIs will only be written 
once we do it, I think.

Ideas on a way forward? Volunteers? I hope in particular Kevin Smith and 
Philipp von Weitershausen have something to say about this. I recall 
them talking about this topic in the past, I think.

Regards,

Martijn



More information about the Grok-dev mailing list