[Cubicweb] Integrating CubicWeb views into Pyramid (long)

aurélien campéas aurelien.campeas at gmail.com
Wed Aug 6 13:22:40 CEST 2014


2014-08-06 11:39 GMT+02:00 Christophe de Vienne <christophe at unlish.com>:

> 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).

Some "components" (which are "small views") or boxes are selected this way.
See APIs such as .possible_appobjects and friends.

> 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.

I didn't know about this one. That's weird. Looks dubious to me.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140806/2581730e/attachment-0186.html>

More information about the Cubicweb mailing list