[Cubicweb] Integrating CubicWeb views into Pyramid (long)
Christophe de Vienne
christophe at unlish.com
Wed Aug 6 11:39:38 CEST 2014
Le 06/08/2014 11:31, Paul Everitt a écrit :
> On Aug 6, 2014, at 10:56 AM, Nicolas Chauvat <nicolas.chauvat at logilab.fr> wrote:
>> On Wed, Aug 06, 2014 at 12:51:48AM +0200, Christophe de Vienne wrote:
>>> For point 2), I am not aware of examples were the weight variation
>>> is actually important in the selection process.
>> As you may have seen, in the current system, the weight is computed
>> and returned by the predicate at evaluation time.
>> If I understood correctly what you suggest, the weight would have to
>> be an attribute of the predicate that could be used at
>> startup/registration time to order the objects in the registry.
>> I am not saying the current system has to be kept that way, it is good
>> to discuss and re-evaluate all design decisions from time to time. I
>> am just pointing things out in order to help the discussion make
>> Search for "return score" in cubicweb/predicates.py to get examples of
>> predicates that will return different weights depending on the
> Pyramid can match views based on information known at configuration (startup) time. But it also have predicates that select a view based on information at request time:
> For example, the "kind of thing" (context class, interface) of the context that the URL points at. Or stuff in the incoming request's HTTP header. Or, the "kinds of things" in the ancestors of the context (the containment predicate.) Or, some custom decision that you make for your application. In other words, Pyramid can also have model-driven view selection.
> What it isn't natural at, though, is when you intentionally want a view configuration to point multiple views. When there is never any information in the graph, nor in the request, to say which view you want. When you either explicitly want a sequence of views (e.g. a list of portlets) or you want the system to take a guess.
I do not think we do that in CubicWeb. All the predicates works with the
current resultset (the pyramid context) or the current request, and the
goal is always to select one view (and again, I talk only for the views,
not the other appobjects).
What the CubicWeb predicates do that pyramid does not is that they
returned a weighted match.
For example, match_user_groups('managers', 'users') will weight more if
the current user belong to both groups instead of just one.
> Surely, when putting the weight on a CubicWeb view, it is based on some policy in the information model. If not, then when would the lower-weighted view ever get used?
I suspect a misunderstanding here : the predicates always works with the
current context & request. If they don't they are mis-used.
More information about the Cubicweb