[z3-five] Question about skins usage

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Philipp von Weitershausen wrote:
> 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".

The "design choice" is tha product authors are not encouraged to feel
that they own the "polciy space":  when you add a product to a Zope2 +
CMF instance, *nothing happens* until the site owner chooses to
incorporate the skins (and other policy choices, like types, workflows,
etc.) into her site.  Those choices can all be made discretely, if she
wishes, althogh the QuickInstaller provides a "just do it" way to short
circuit making those choices for many.  Even in the case of the
QuickInstaller-driven site, it is feasible to *override* the presents
after doing the install (e.g., to move a laywer "down" in the stack, or
delete it altogether from a skin).

The "flat acquisition namespace" for skin objects is an entirely
different problem, for which Zope3's view mechanism is the obvious remedy.

In Zope3, the policy choice is essentially all or nothing:  you either
include the package's ZCML slug, or you copy its configuration wholesale
and hack on the copy.  Most add-on authors (and much of the core!) do
not factor their ZCML in ways that would ease this (i.e., by splitting
directives up into fragments built around granularity of reuse).  ZCML
itself allows for only the crudest override mechanism.

I actually argued *long* ago (December 2001, after the first ZC-internal
Zope3 sprint) that the <include> directive in ZCML (it was spelled
differently then) should allow for nested subdirectives which controlled
*how* the included file's actions were processed.  In particular, I
wanted individual directives in the included file to be excludable based
on their 'id' attributes, e.g.::

  <!-- DRINK ME! -->
  <configure xmlns="http://namespaces.zope.org/zope">
   <adapter id="foo"
            factory=".path.to.aklass" />
   <utility id="bar"
            factory=".path.to.uklass" />
  </configure>

  <!-- site.zcml -->
  <configure xmlns="http://namespaces.zope.org/zope">
   <include package="wonderland" file="drink_me.zcml">
    <enable target="bar" />
   </include>
  </configure>

This "proposal" obviously requires that parsing a ZCML file be free of
side-effects, which was why Jim and Shane vetoed it at the time.  Of
course, the fact is that side-effect-free ZCML parsing would be a big
win for other purposes, too.


> 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 don't think ZCML's condition bit puts the responsibility in the right
place:  the "mechanism" (the included file) ends up enforcing "policy"
signalled by way of some global variable.  I'd rather "pull" mechanism
into policy selectively, than "push" policy into mechanism.

>>>> 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 :)


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEx18X+gerLs4ltQ4RAhRxAJ9o2IvXohyMz/yHnNy/z7Qb+018SgCeJLaB
kPS1QIe/7heO+uA9zSb7u+c=
=1AcG
-----END PGP SIGNATURE-----