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

Jan-Wijbrand Kolman janwijbrand at gmail.com
Wed Dec 17 11:04:46 EST 2008

Brandon Craig Rhodes wrote:
> I understand that whoever wrote the following definition in
> `grok.interfaces` was doing something that looks quite reasonable; the
> superclass is a Request-thing, so shouldn't the class also indicate that
> in its name::
>     class IRESTRequest(IHTTPRequest):
>         """REST-specific Request functionality.
>         Base Interfaces for defining REST-layers.
>         """
> But the way that an `IRESTRequest` is actually used, always, and in
> every context that I can find it used, is as a base class for a REST
> layer.  Therefore, I think that it should be renamed to `IRESTLayer`,
> and that `IRESTRequest` should be left around as a synonym to avoid
> breaking old code that has already used that name - but that the name
> should be put through deprecation, either now, or some time after 1.0.
> This would mean that definitions like the following one, from the file
> `grok/ftests/rest/rest.py'::
>     class LayerC(grok.IRESTRequest):
>         grok.restskin('c')
> would become the much more sensible::
>     class LayerC(grok.IRESTLayer):
>         grok.restskin('c')

(The code was written in order to fix:

-1 on the rename.

Rationale: The naming scheme is *intentionally* similar to how "normal
view" layers and skin work, because, well, the mechanisms are similar to
a great great extend.

You first point is especially well put (in favor of not renaming) as
"layers" really are subclasses of the request interface.

As such it is way easier to understand (at least that is how I
experienced it), how REST "views" actually works.

Breaking old code is still not an issue in my humble opinion. After 1.0
it will be (we intentionally broke backwards compatibility for "view"
layers and skin in an identical way in 0.14 too BTW).


More information about the Grok-dev mailing list