[z3-five] Question about skins usage

[Philipp von Weitershausen]

Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>>> Tres Seaver wrote:
>>>> Paul Winkler wrote:
>>>>>> On Tue, Jul 25, 2006 at 01:47:16PM +0200, Philipp von Weitershausen wrote:
>>>>>>> Why? The one-layer-per-product rule from the CMF is pretty stupid.
>>>>>> Which rule is that? My old CMF code frequently used multiple layers.
>>>> Hmmm, maybe Philipp doesn't really believe in layers?  The original
>>>> point of layering was to allow reuse-with-override;  later, the layers
>>>> became a way to organize "related" skin objects on disk.  If you aren't
>>>> trying for those goals, then layers are definitely overhead you don't need.
>>> I do like layers. What I don't like is a common pattern in CMF, or
>>> rather, in extension products for the CMF which makes up for the missing
>>> "default" layer in the CMF.
> 
> Its absence is *by design* (see below).

That's almost hard to believe (though surely not impossible). I would
have guessed it's as much "by design" as the big flat namespace in the
CMF is by design (which yields to view names like document_edit_form and
document_view instead of just edit and view). Surely *somebody* made the
CMF use implicit acquisition throughout... that doesn't mean it was a
"design choice".

>>> Say you have a blog product for the CMF, and blog objects have an edit
>>> form (blog_edit_form) and a display page (blog_view). These views are
>>> typically on the filesystem. Now the product wants to get them into the
>>> CMF. The only way to sanely do that is to put them into a directory,
>>> register that directory as a layer in the skins tool AND (this is the
>>> wicked part) modify all skins to include this layer.
>>>
>>> I don't think layers were made for that. There's no reason for these
>>> standard (!) object views to be on a special layer that you can switch
>>> on or off, that your skin can decide to include or not. They should just
>>> be "there". That's why we have the "default" layer in Zope 3.
> 
> That makes the product harder to reuse, as the "policy" choices are
> embedded in the product.  (We don't yet have a reasonable way to include
> only part of an add-on's configuration in ZCML, or to disable part of it
> after inclusion).  Layering in the CMF means that including skin methods
> ("views") from an add-on product is an explicit choice, with per-layer
> granularity.  In Zope3, the granularity tneds to be "per add-on", as
> many add-ons have *all* their configuratoin lumped together.

I don't question the flexibility and usefulness of all this. I'm still a
fan of layers, but I also think they're just overdone in the CMF. You
have to jump through lots of hoops just to get a simple view Page
Template publishable from the filesystem. And of all, the common install
'trick' that monkeys with all existing skins so that they include the
new layer turns my stomach...

Of course, having a "default" layer doesn't mean you can't do all this
in Zope 3. If you deliberately put all the stuff from different packages
in different layers, you basically end up with what the CMF has got. It
just doesn't seem common practice... (and I think I know why: nobody
needs it).

As for granularity of configuration, I think we could be making use of
zcml:condition a lot more to make thigns more flexible. Surely, 3rd
party packages that want to be very flexible (e.g. the CMF) can
encourage its usage.

>>> I find layers useful, but only in one context: producing skins. The
>>> "default" layer has no skinning, that's what specialized layers are for.
>>> I'd say 99% of the things I would put on a layer other than the default
>>> one is skin-related (skin macro, resources like logo images, CSS,
>>> JavaScript, etc.).
> 
> I don't think we have enough experience in the Zope3 world with
> combining large numbers of third-party products, and tweaking the
> resulting highly-complex configuration, to claim that Zope3's model is
> intrinsically superior to the one evolved for Zope2 + CMF.

You're right, we don't. But I *do* have enough experience with the
evolved one for Zope2 + CMF to know what I don't like about them. And
this is one :)

Philipp