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 

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 
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 
Layer interfaces are just marker interfaces; if we'd treat every kind of marker 
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 
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 won't require an 
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 
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 
suggestions and get started on the implementation (on a branch, of course).


This message was sent using IMP, the Internet Messaging Program.
Zope3-dev mailing list

Reply via email to