[Cubicweb] PYRAMID: Traversal

Paul Everitt paul at agendaless.com
Mon Jul 28 15:32:49 CEST 2014

On Jul 28, 2014, at 2:32 PM, Nicolas Chauvat <nicolas.chauvat at logilab.fr> wrote:

> On Mon, Jul 28, 2014 at 09:35:14AM +0200, Paul Everitt wrote:
>> When I heard the description of the way views in CubicWeb are looked
>> up, it made me think of Pyramid's traversal, which is designed for
>> graphs. It's possible that traversal is precisely the right approach
>> for CubicWeb and, if used, would bring in a number of benefits:
> Interesting thought. I am not sure what you see as common between
> using cubicweb's registry to select a view and traversal, but will go
> read again about traversal.

Looking at this:


...you have a system that appears to map a URL to a process that walks through the graph, selecting views and performing work. The "default evaluator chain" you describe in there is something like traversal.

Most systems use routes as a way to match a URL string to code that generates a response. Traversal treats the parts of the URL as object/subobject references that end in a view. The policies for taking the identifier for a subobject identifier and getting the subobject is either __getitem__ or your own custom code. This has a number of benefits:

- Walking around the system and assembling content and logic is moved from user code (route patterns) to framework code
- Policies such as security and caching can be enforced in the framework
- Arbitrary hierachies can be constructed without stupid placeholders in the URLs such as /people/1/documents/2
- Opens up a number of interested view predicates to specialize the location of view code


More information about the Cubicweb mailing list