[Cubicweb] PYRAMID: render_view
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:
> 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, but with a selection
> process that uses the whole context of the call, not only the function
> 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