[Cubicweb] Integrating CubicWeb views into Pyramid (long)
florent.cayre at logilab.fr
Tue Aug 5 10:20:01 CEST 2014
thanks for sharing your thoughts and pushing that hard towards a good
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 :
> 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
I understand it does not hold what you call "runtime" information like
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
> 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
correct). This could be a performance improvement, but nothing required
in a first
> Integrating CW Views
> Goal: Have Cubicweb Views selected by pyramid.
Nice goal. Let's start with this one alone before thinking to the next
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
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.
> * 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.
> * 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
> the cubicweb predicates.
> * We by-pass the CW registry
> * 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
> This would need either a slight change of the pyramid MultiView, which
> 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
> predicate expressions for add_view.
> The only blocking point against that would be if some actual cw
> 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
holds): the logged-in user (known at web-request time) for example, is
to compute a predicate weight (match_user_groups
and so the web query parameters
for example, but there is a complete list in the CW doc).
> * By-pass the CW registry
> * Very integrated solution
> * 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
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
not fit (which I am still unsure, see my previous question), we will
with a re-implementation of CW registry features in Pyramid, which may
be interesting for the Pyramid community. Paul probably has a good idea
> 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,
> Cubicweb mailing list
> Cubicweb at lists.cubicweb.org
More information about the Cubicweb