[Zope3-dev] RFC: Simplify Skinning Redux

[Philipp von Weitershausen]

Stephan Richter wrote:
> On Monday 12 December 2005 16:29, Dominik Huber wrote:
> > 1. The brand *skin* and *layer* are fairly common and they are
> > reflecting two logical uses cases. At a first glance the usage for a
> > layer type is not given, but the layer concept is still interesting to
> > build modular skins. The layer audience could be the developers which
> > like to share layer specific informations. IMO an use case for an
> > Browser Layer Names utility could be a corresponding
> > online-documentation within the api-doc.

Well, the vocabulary would probably be a "Browser Layers" vocabulary (listing the actual
interface objects, not their names, since layers won't have human-readable aliases
anymore).

However, I don't see how that vocabulary would be necessary for the documentation (it
would be necessary for TTW development, see below). It's not like we mark every interface
we have with some special marker and put it in a vocabulary, just so it shows up in a
certain category in APIDoc. If you want to find the layer interface, you'll find it just
fine by walking the code browser in APIDoc, as with any other interface or component.
Layer interfaces are just marker interfaces; if we'd treat every kind of marker interface
specially, we'd not be simplifying at all...

> > I would suggest to register the
> > layers like skins using a ILayerBrowserType interface:
> >
> > <interface
> >           interface=".interfaces.I18NFeatures"
> >           type="zope.publisher.interfaces.browser.IBrowserLayerType"
> >           />
> >
> >
> > 2. I liked the naming ISkinType and ILayerType much more (instead of
> > IBrowserSkinType/ IBrowserLayerType), because this browser-specific
> > differentiation is already given by the package hierarchy and those
> > ILongCamelCaseWordingsThatTriesToExplainEverything are hard to type and
> > at the end they confuse newcomers even more than the simple ones. Please
> > keep the naming also simple and stupid like the skinning simplification
> > itself  :)

I don't feel strongly about this at all. It was mostly Steve's idea and I took his
suggestion as it adds some conherence (IBrowserRequest, IBrowserResponse,
IBrowserLayerType, ...). It would be up to Steve to defend it, for all I care we can use
the shorter forms.

> Two good points I agree with. I wanted to write a similar response as 1., but
> did not have a good argument. Dominik just gave it. I think it is important
> to keep a registry of all layers, especially for TTW development, an area I
> really want to put some effort in for 3.3.

Thanks, I guess this is a good use case. The good thing is that the whole ILayerType thing
can be *optional*. The 'type' argument of browser:page et.al. won't require an ILayerType
interface; any interface will do as long as it is or extends IBrowserRequest. Only if you
want your layer interface to show up for TTW view registration, you'll need ILayerType so
that it shows up in the "Browser Layers" vocabulary and thus among the list of selectable
layer interfaces.
That said, I still think that in the long term, local registration should not be done TTW.
So this optional notion of ILayerType might not be necessary in the future after all. For
filesystem-based development I don't find any compelling usage for it at all.

So, if there are no other comments on this proposal, I will update it with your latest
suggestions and get started on the implementation (on a branch, of course).

Philipp


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