[Cubicweb] PYRAMID: render_view

Paul Everitt paul at agendaless.com
Fri Jul 11 15:16:00 CEST 2014

On Jul 10, 2014, at 10:45 AM, Christophe de Vienne <christophe at unlish.com> wrote:

> Le 10/07/2014 15:44, Nicolas Chauvat a écrit :
>> On Thu, Jul 10, 2014 at 09:09:00AM -0400, Paul Everitt wrote:
>>> For the case of views, however, Pyramid provides a pretty rich (and extensible) matching system:
>>>  http://docs.pylonsproject.org/projects/pyramid/en/1.1-branch/narr/viewconfig.html#predicate-arguments
>> Interesting.
>>> This part of the discussion probably can be deferred, as it would likely be the last thing you would do.
>> True.
>>>> Does the above help, or does it make things fuzzier? :)
>>> Perhaps the way to think about it then is that the Pyramid concept
>>> called "view" is under discussion for the top/outer view that
>>> interfaces to the outside system, while the CubicWeb concept of view
>>> is still retained for the internal process of selection and
>>> assembly?
>> Yes.
>> Last time I discussed this with Christophe, he was describing an
>> implementation where you could use pyramid's routes to mix pyramid
>> views (for some routes) and a cubicweb "handler" (for some other
>> routes). The cubicweb "handler" would do its own thing: execute a
>> query, find the best possible view and apply it to generate the
>> output.
> We will discover the right formula soon I guess, and my current opinion
> is that we can simply drop the following from CubicWeb and replace it
> with pyramid based components :
> - SessionManager, WebAuthRetriever -> replaced by their pyramid
> equivalent (almost done)
> - URLPublishers, Controllers -> replaced with pyramid route, resource
> locator and view.
> - CubicWebPublisher -> becomes unnecessary. The current handler I am
> implementing will serve as a backward compatibility layer for cubes that
> still make use  of Controllers.
> In this approach, the cubicweb "handler" that execute the query and find
> the right view is reincarnated in a resource locator and the pyramid
> view selection.
> We should be able to register the top-level cubicweb views as pyramid
> views with a very thin wrapper, and use the cubicweb predicates directly
> when registering views in pyramid.

I propose that I stop with all these deep tangential discussions and instead focus on what you have here. :)

I think we should start filling out your sample app. As a sequence of steps:

1) Get something that doesn't use CubicWeb, just returns some dummy data. Basically the Pyramid scaffold output.

2) Change one of the Pyramid views to brute-force the retrieval of something from CubicWeb. All inside the view. No refactoring to take advantage of Pyramid. Have the demo application get the CubicWeb application bootstrapped with some sample data.

Doing this will help me avoid having to learn CubicWeb.

3) Take one of the parts that is buried in the view, and move it out to the appropriate place. I see you already doing this a little with the request methods for session/cnx/request.

4) Write some tests on the sample app. This is helpful, as it puts focus on the CubicWeb developer's experience with this.

5) Move some more things out and get to a nice sample application.

> At this point the release of a pyramid based cubicweb would make sense,
> and it would remain very compatible.
> After that, other things can be studied, like:
> - the form generation
> - dropping the repository sessions and authentication
> - use colander for complex input validation (which would hugely simplify
> the editcontroller)
> - rethink the cubicweb view API
> - use venusian to populate the registry
> - make the cubicweb registry based on the pyramid one

All interesting choices. I was also going to suggest your transaction concept, perhaps integrate it with pyramid_tm or go even further.


More information about the Cubicweb mailing list