[Cubicweb] Integrating CubicWeb views into Pyramid (long)

Florent Cayré florent.cayre at logilab.fr
Tue Aug 5 10:20:01 CEST 2014

Hi Christophe,

thanks for sharing your thoughts and pushing that hard towards a good
Pyramid/CubicWeb integration.

I am a complete newbie on Pyramid and could not attend last meeting, so 
be tolerant if my questions were already answered there.


Le 04/08/2014 20:59, Christophe de Vienne a écrit :
> [snip]
> Registering a View
> ~~~~~~~~~~~~~~~~~~
> When we register a view in Pyramid, we pass various parameters to the
> "add_view" function (or view_config decorator).
> Three of them are the informations used for the first phase of the view
> selection (later I call them the main predicates triplet):
> - context

What kind of information does this context hold? From what follows in 
you email,
I understand it does not hold what you call "runtime" information like 
the user
that performs the request and the web-session data. Is this "context" 
known at view "registration time" (as opposed to "web-request time")?

> - name
> - request_type
> Other parameters are predicates, like `accept`, `xhr` etc. These are 
> evaluated
> in a second phase, once the view(s) matching the first three are found.

These are thus evaluated at web-request time, correct? Why not use these to
evaluate the CW predicates? More on this later.

Maybe we should split CW predicates into two categories in the long 
term: some may
be more as a context (and evaluated and registration time if my 
understanding is
correct). This could be a performance improvement, but nothing required 
in a first

> [snip]
> Integrating CW Views
> --------------------
> Goal: Have Cubicweb Views selected by pyramid.

Nice goal. Let's start with this one alone before thinking to the next 
one (namely
bypass the CW registry, more on this below).

> The selection behavior should be consistent with the cw predicates 
> weight based
> priority system.
> Several approaches should be studied, some less integrated than others.
> Use a ViewMapper
> ~~~~~~~~~~~~~~~~
> [snip]

Not sure I understood this, but you seem to dislike it so much that you 
know what you are saying :-)

> Use a custom IMultiView
> ~~~~~~~~~~~~~~~~~~~~~~~
> Implements a IMultiView (see pyramid.config.views.MultiView) that 
> lookups in
> the CW registry in hits __discriminator__.
> One instance of this class would be registered for each __regid__, 
> like with
> the ViewMapper-based solution.
> Pros
>     *   Not too difficult to implement
>     *   Respect more the pyramid API: the lookup is performed at a 
> moment it is
>         expected by pyramid. In the end, pyramid will know the right 
> view, and
>         any other system looking up for a view will find an actual 
> one, not a
>         pseudo one.
> Cons
>     *   The CW views are not registered directly in pyramid
>     *   Still doing two lookups in two different registries.

IMHO, this is a first step we could make because:

* removing CW registries is not the goal you just mentioned, which seems 
   important to me in the short term

* the second cons you mention is not that bad: in this scenario, the Pyramid
   registry is more like a one-element list per __regid__, which should 
not be a
   hard performance penalty

* it really looks like a natural and simple approach, not a hack: not 
   to understand, easy to debug... ok for me, at least as a first step

> Use CW predicates in add_view (basic)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Here we add a "cwselect" predicate to pyramid, that makes it able to 
> evaluate
> the cubicweb predicates.
> Pros
>     *   We by-pass the CW registry
> Cons
>     *   We loose the cw predicate weigths

I am -1 because of this last point.

> Use CW predicates in add_view + total ordering
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Here we choose to drop the runtime evaluation of the predicates weight.
> Instead, we evaluate the weight of a predicate when it matches, and 
> use that to
> sort the views in the registry.

I do not understand this: is the predicate weight evaluated or not? If 
yes, when?

> This would need either a slight change of the pyramid MultiView, which 
> would
> sort the views in this new order we compute instead of the default 
> one, or a
> change in the 'make' function so that the order of the view includes the
> To use this system, we would need to duplicate the view registering 
> when the
> expression has some "or" operators in it. The idea is to obtain 
> 'and-only'
> predicate expressions for add_view.
> The only blocking point against that would be if some actual cw 
> predicates
> returns a variable weight depending on the context, because it would 
> make it
> impossible to pre-evaluate an expression weight if it matches.

This depends on what the context is (see my first question about what 
the context
holds): the logged-in user (known at web-request time) for example, is 
often used
to compute a predicate weight (match_user_groups 
and so the web query parameters
(in match_form_kwargs 
for example, but there is a complete list in the CW doc).

> Pros
>     * By-pass the CW registry
>     * Very integrated solution
> Cons
>     * We force the predicates to have a fixed value when they match.

I do not understand this, but the impression I got reading your email is 
that the
Pyramid registry ordering thing is too static to be used as a selection 
However you mentioned a second predicate evaluation step at the 
beginning of you
email, that should fulfill CW needs unless I misunderstood all this.

> Use CW predicates in add_view + cw predicate weight
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Add runtine evalution of predicate weigths into pyramid.

This looks like a nice second step to me, but I am still unsure what the 
would be: drop CW registries completely? If you think that Pyramid 
registries do
not fit (which I am still unsure, see my previous question), we will 
more end-up
with a re-implementation of CW registry features in Pyramid, which may 
(or not)
be interesting for the Pyramid community. Paul probably has a good idea 
of the

> No real clue on how we can to that (yet), although it will most probably
> involve changes in MultiView.
> Thank you if you made it so far, and please tell me what you think of 
> the various
>  options, we need opinions to make progress.
> Best regards,
> Christophe
> _______________________________________________
> Cubicweb mailing list
> Cubicweb at lists.cubicweb.org
> http://lists.cubicweb.org/mailman/listinfo/cubicweb

More information about the Cubicweb mailing list