[Zope3-dev] RFC: Simplify Skinning Redux

[Steve Alexander]

>>>I would suggest to register the
>>>layers like skins using a ILayerBrowserType interface:
>>>
>>><interface
>>>          interface=".interfaces.I18NFeatures"
>>>          type="zope.publisher.interfaces.browser.IBrowserLayerType"
>>>          />

It is simple to create a zcml directive specifically for registering a
layer.  If there is a good reason to register layers, then I think there
should be a zcml directive for it.

Of course, it may be that there's not really a good reason for
registering layers.


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

Who will use these interfaces?  In what parts of the code will they be
present?

I think these marker interfaces are used only in infrastructure code to
do with setting up layers and skins.  In this case, they will not be
typed often, and will not even be read often.  So, I think it is more
important that the name be clear than the name be short, so that it can
be understood quickly upon reading it.


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

Why do you need a registry of all layers?  What use-cases drive this
requirement?  Maybe you just need to be able to look them up?


> Thanks, I guess this is a good use case. The good thing is that the whole ILayerType thing
> can be *optional*.

This is important to me.  The core of a publisher-with-layers can be
based on just a request's interfaces.  No need for extra complexity or
infrastructure.  It should be possible to strip a use of Zope 3 down to
this level.

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

This is important too.


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

I strongly support this being an optional feature; a price you pay only
if you care about TTW stuff.


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

Me too.


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

-- 
Steve Alexander