[Cubicweb] meeting with Paul Everitt "a Pyramid guy" on July 31st 2014 at Logilab

Paul Everitt paul at agendaless.com
Mon Jul 28 16:08:57 CEST 2014

On Jul 28, 2014, at 3:29 PM, Christophe de Vienne <christophe at unlish.com> wrote:

> Le 28/07/2014 14:32, Nicolas Chauvat a écrit :
>> On Mon, Jul 28, 2014 at 09:35:14AM +0200, Paul Everitt wrote:
>>> When I heard the description of the way views in CubicWeb are looked
>>> up, it made me think of Pyramid's traversal, which is designed for
>>> graphs. It's possible that traversal is precisely the right approach
>>> for CubicWeb and, if used, would bring in a number of benefits:
>> Interesting thought. I am not sure what you see as common between
>> using cubicweb's registry to select a view and traversal, but will go
>> read again about traversal.
> In my understanding, the traversal would build the rset, like the RestPathEvaluator does, and make a context out of it.
> This context would be fed to the cubicweb predicates by the pyramid view selection system.
> Hence, the common is not between traversal and cubicweb registry selection, but between traversal and RestPathEvaluator, and between the cubicweb registry and the pyramid registry.
> Note that it does'nt mean we remove the cubicweb registry for view selection in general (yet), just that we can bypass it for the top-level view.
> Also, it means that the way views are chosen by the end-user will probably need to change from "/somepath?vid=someview" to "/somepath/someview". I personnally think it is for the best, as using the query parameters for view selection (and for rql query anywhere in the application) looks like bad practice to me.

In a word: correct! :) Although there are more benefits than just cleaning up bad practice. As a note, I don't think this will require changing CubicWeb, just the way Pyramid integrates with it. If you think this is worth a Skype call, let me know. It would be nice to decide soon whether this is worth investigating this week.


More information about the Cubicweb mailing list