[Cubicweb] Integrating CubicWeb views into Pyramid (long)

Christophe de Vienne christophe at unlish.com
Wed Aug 6 12:06:28 CEST 2014

Le 06/08/2014 00:51, Christophe de Vienne a écrit :
> [...]
> I have the impression that in most (if not all) cases, the views (and 
> I am talking only about the views) could be ordered even before any 
> actual evaluation of the predicates.
> For example, let's consider the two expressions :
>     __select__ = is_instance('Event')
> and
>     __select__ = is_instance('Event') & match_user_groups('managers')
> If the first one matches, its weight would be 1.0
> It the second one matches, its weight would be 2.0
> Hence, the second one has a higher priority. If it matches, we don't 
> need to evaluate the first one -> it would have a lesser weight 
> whether it matches or not.
> This only works if 1) we have no 'or' 2) the predicates have a fixed 
> weight once in the expression.
> For point 1), the solution is to split the expression and register the 
> view twice (or more). For example :
>     __select__ = is_instance("Event") & match_user_groups('managers') 
> | is_instance("SmallEvent") & match_user_groups("users")
> A view with such a select would be registered twice, with different 
> expressions:
>     is_instance("Event") & match_user_groups('managers')
> and
>     is_instance("SmallEvent") & match_user_groups("users")
> For point 2), I am not aware of examples were the weight variation is 
> actually important in the selection process.

I just realized: this point 2) can be handled, in many case, the same 
way than point 1). A predicate that has a variable weight can actually 
be 'developed' into an expression with only fixed-weight predicates.

For example, match_user_groups('manager', 'users') is almost equivalent to :
match_user_group('manager') | match_user_group('users') | 
match_user_group('manager') & match_user_group('users')

And this expression is splittable into 3 expressions that we can sort by 
weight and evaluate in the right order.

Note that this discussion is a bit early for the very next step of the 
pyramid/cubicweb integration, and a little off-topic too, as we will 
soon speak about optimizing selection. But it is worth having the ideas 
written for later use.



More information about the Cubicweb mailing list