[Zope3-dev] Re: Last chance to comment on Simplify skinning

Jeff Shell eucci.group at gmail.com
Wed Feb 15 23:05:24 EST 2006


On 2/15/06, Philipp von Weitershausen <philipp at weitershausen.de> wrote:
> I find Zope 3's approach much simpler and much easier to explain than
> the CMF's approach. In Zope 3 (especially with my proposed changes in
> place), a layer is simply a label (read: marker interface) on the
> request. When we now look up pages and resources (e.g. images), we take
> the request into account and therefore inevitably that label. We will
> only find pages and resources associated (read: registered) for this
> label. Good news is that any page or resource can be associated for this
> label, we just have to remember to do that in their ZCML directive.

When you say "with my proposed changes in place", I don't understand
how that differs from what currently exists, or what can exist. We at
Bottlerocket started serious Zope 3 work with Zope 3.1. We've been
defining skins and layers as Interfaces since that time. I didn't
understand it entirely at first, but when I was debugging some issues
that arose with a fix to multi-adapter lookup that came in Zope 3.2, I
understood it more, and now it makes a lot of sense to me.

So coming from that world, I'm not entirely sure I understand how your
proposal is really different, except for this:

In your proposal, 'Skins' are just gone as a separate concept - yes?
What is now treated as a Layer can also be treated directly as a skin,
yes?

Here's a situation from a recent application of mine. The comments and
doc strings are verbatim. Notice that I leave a number of breadcrumbs
behind about which is the skin and which is the layer::

    # Layer
    class KBase(IBrowserRequest):
        """ The ``kbase.skin.KBase`` **Layer** """

    # Skin
    class KnowledgeBase(KBase, CMS, IDefaultBrowserLayer):
        """
        The Knowledge Base Skin. Uses the CMS layer, but **not** rotterdam.

        The Knowledge Base skin is very specialized and does not need as many
        generic features as the Content Management or default ZMI skins. The
        primary dependance on the CMS layer is to get its resources (javascript
        libraries, icons).
        """

I assign most things in my application to the KBase layer. The
KnowledgeBase Skin builds from three layers. Very early versions of
this app did a mix of layers and skins in the bases used for
``KnowledgeBase``, but the skin it used brought in too many views that
I didn't want interfering with things accidentally, so I went with the
``CMS`` layer instead so I'd get things from our CMS layer, but not
get *everything* that was chosen for the *Content Management* skin.

Does that make sense?

If I understand your proposal correctly, the Layer and Skin above
would both basically be the same thing, right? The only thing that I
guess really differentiates them right now (in my application) is how
they're registered in ZCML. But they're each the same basic collection
of interfaces. ``KBase`` is shallow and dedicated to the browser
view/resource components in my application, ``KnowledgeBase`` is rich
and pulls in components from others.

The only thing that I don't understand right now is this concept of
Interface Types. I don't have our Zope 3 book in front of me right
now, so I'm not sure if it has anything helpful to say. But I'll just
say that Interface Types have been an elusive concept for me, so far.

--
Jeff Shell


More information about the Zope3-dev mailing list