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

[Philipp von Weitershausen]

Jeff Shell 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.

Cool!

> 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?

Yes, you are right, that's basically the only change my proposal advocates (and
some minor details around it).

> 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?

Not necessarily. You're free to create whichever layer hierarchy suits you
best. At some point you can then say that a particular layer in that hierarchy
(typically one that combines a lot of other layers) becomes known under a
human-readable name. We then say it's a skin.

My proposal gives you the freedom to promote any layer to a skin. That means
you can also register views directly for a skin because it's just another
layer. You won't have to create a layer and then a skin based on that layer...

> 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.

Interfaces mark objects. Like "This is a recipe" or "This is
attribute-annotatable". Interface types mark interfaces. Like "This is not
just some interface, it's an interface for content components" or "This is an
interface we use as a skin". When you got my book in front of you, look up the
beginning of Chapter 5.

Interfaces extend z.i.Interface. Interface types extend z.i.i.IInterface
(notice the double I) because they describe interfaces.

Philipp


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.