[Grok-dev] could we re-name grok.IRESTRequest to grok.IRESTLayer?

Martijn Faassen faassen at startifact.com
Thu Dec 18 10:01:40 EST 2008

cd  Jan-Wijbrand Kolman wrote:
> Brandon Craig Rhodes wrote:
>> EDIT: or, if "IRESTSkin" tells the web developer even more clearly how
>> he's supposed to use the class, then that's an even better option.  But
>> I'm going to defer to people with more Zope years than I have whether
>> the term "Layer" or "Skin" will be better here and in all of our REST
>> test cases.  Once it's decided, I'll happily jump in and do the renaming
>> myself for us.
> 1) Renaming it to IRESTSkin is not an option if you'd ask me: it would
> mix up the terminology involved in layers&skins:

Agreed. These things are layers, not skins. We register a layer as a 
skin by setting the directive on them.

(Now I do think that is slightly unusual - usually registration happens 
because of the presence of a base class and directives only supplement 
this behavior and do not directly cause registration. Ideas?)

> 2) I'm still not really in favor of renaming it to IRESTLayer. But not
> religiously so. I do think though, that if it is decided to have renamed
> to IRESTLayer, we should consider again introducing a IBrowserLayer base
> interfaces as well; I really do like to keep the symmetry here - it was
> the lack of symmetry before that confused me (mind you, me as in a
> developer *with* grok).

We do need the symmetry.

I'm leaning slightly in favor of having a IViewLayer and a IRESTLayer, 
as opposed to IBrowserRequest and IRESTRequest. IViewLayer would be a 
simple subclass of IBrowserRequest. I think "View" is better than 
"Browser" too - these are layers people use for their views.

I think this naming discussion shows that exposing the request-like 
nature of layers confuses here as much as it might enlighten. I think 
it's clearer for people to think: "I'm going to make a layer here for my 
views, and I need to subclass it from grok.interfaces.IViewLayer" and 
aren't distracted by how this works internally. That knowledge may be 
*useful* but it's not essential to an understanding how layers behave 



More information about the Grok-dev mailing list