[Cubicweb] PYRAMID: render_view

Paul Everitt paul at agendaless.com
Thu Jul 10 15:09:00 CEST 2014

On Jul 9, 2014, at 4:44 PM, Nicolas Chauvat <nicolas.chauvat at logilab.fr> wrote:

> Hi,
> On Wed, Jul 09, 2014 at 09:42:39PM +0200, Christophe de Vienne wrote:
>> That said, at one point we will want to dig into the two registries and
>> evaluate how much they have in common.
> I did not dig into the code to check what I am about to say, but I
> would bet Pyramid's registry is focused on selecting items based on
> interfaces (IMailable, IPlottable, or whatever), whereas CubicWeb's
> registries are trying to be more generic (but probably less efficient)
> and have a selection mechanism based on a score function (composed of
> predicates/functions) that takes the context as its argument.
> An example would be:
> __select__ = authenticated_user() & is_instance('Project') \
>             & rql_condition('X has_contributor U')
> that will return a positive score if the user is authenticated, the
> data to display is a list of projects and the current user is a
> contributor to all the projects of the list.
> AFAIK, this goes further than zope.component's selection.

It is true that the ZCA doesn't go that far. For the case of views, however, Pyramid provides a pretty rich (and extensible) matching system:


This part of the discussion probably can be deferred, as it would likely be the last thing you would do.

>> The way I see them, views can be (and are) used to build web response
>> content, but they can be used to do other things. For example we use
>> them to build email content, or xml/json/rdf/(and more) representations
>> of the datas.
>> We could describe them as an adaptive templating system : views uses
>> each others to build a consistent representation of a dataset, and the
>> predicate-based selectors allow to override a view for specific cases.
> Views are functions. They take the context/data as input, they can
> call whatever code/functions/views they want during their execution,
> and they return a string/binary. The first/top view that is called
> hence returns the body of the response.
> Views are stored in registries, keyed by their name. Components
> (cubes) can add to the registries their own views with the same name,
> but a different selection function that will return a higher score in
> a specific context.
> If views behave well and call other views after looking them up in the
> registries instead of shortcutting via the python modules, it entails
> a system that is similar to generic functions[1], but with a selection
> process that uses the whole context of the call, not only the function
> signature.
> Does the above help, or does it make things fuzzier? :)

Perhaps the way to think about it then is that the Pyramid concept called "view" is under discussion for the top/outer view that interfaces to the outside system, while the CubicWeb concept of view is still retained for the internal process of selection and assembly?


More information about the Cubicweb mailing list