[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