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

Christophe de Vienne christophe at unlish.com
Mon Jul 28 16:50:06 CEST 2014

Le 28/07/2014 16:08, Paul Everitt a écrit :
> 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.

I have a feeling that this particular subject is almost a bonus for 
thursday. I would like to work on it asap (I did since the beginning of 
this experiment), but I know other things needs to be done first.

It should at least discuss it a little and 1) explain and make it well 
understood by everyone 2) investigate what would need to be done to 
achieve it.

This way, when we actually start coding on it, people knows where we are 

That said, I would like to know logilab developers expectations about 
this day (mine is to validate the path we are taking and agree on a 



More information about the Cubicweb mailing list