[Cubicweb] PYRAMID: render_view

Paul Everitt paul at agendaless.com
Wed Jul 9 22:44:34 CEST 2014

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

> Hello Paul,
> Thanks for sharing your wisdom with us, it will certainly help us to
> succeed in our attempt to breed CubicWeb and Pyramid !

I think this is going to be a fun investigation, hopefully with a happy conclusion.

> Le 08/07/2014 15:29, Paul Everitt a écrit :
>> Hi everybody, I'm Paul, one of the Pyramid guys. Nicolas and I know each other from way back, first met him at Saarbrucken in 2002. 
>> I told Nicolas I would give some comments on places to use Pyramid as a framework-framework. I'm not a Pyramid superhero nor do I know anything about CubicWeb. But I do give Pyramid training and have collected some material for a Pyramid Add-on Developer Guide.
>> Rather than one big email, I'll try to pick some individual topics, starting with render_view:
>>  https://bitbucket.org/unlish/pyramid_cubicweb/src/07089fd649afaf50e0d0aee01be19100965c9b02/pyramid_cubicweb/__init__.py?at=default#cl-85
>> There might be some better ways to approach this, but first I need some background on the intent. It looks like CubicWeb has a registry. Pyramid does also. In the beginning, of course, you won't look at switching away from your registry. 
> The cubicweb registry will probably stay in the long term because it
> handle things that are not purely web related, like database hooks. As
> such, it may be used from outside a web application, like a shell
> script, and it should remain usable without pyramid at all.

As a note, the Pyramid registration system is a general-purpose registration system. It isn't specific to the web. Really, it's a layer over the zope component architecture and its registration principles. As an example, we use it all the time for non-web console scripts:


> That said, at one point we will want to dig into the two registries and
> evaluate how much they have in common.
>> The comment for render_view says:
>>    # XXX The select() function could, know how to handle a pyramid
>>    # request, and feed it directly to the views that supports it.
>>    # On the other hand, we could refine the View concept and decide it works
>>    # with a cnx, and never with a WebRequest
>> It then looks like you head over into CubicWebLand to manage the request and return a response.
> Somehow yes, but direct management of the request and response by the
> views is a point that needs discussions and decisions to be made.


> The way I see them, views can be (and are) used to build web response
> content, but they can be used to do other things. For example we use
> them to build email content, or xml/json/rdf/(and more) representations
> of the datas.

Pyramid views don't have to return HTML. Used correctly, they just return Python data which is pumped through a renderer:


The renderer might be a template that serializes to HTML. Or the JSON renderer. Or a CSV renderer. Or a custom renderer.

For the most part, the main semantic imposed is that there is a request and a response and kind of thinks HTTP is the transport. After that, it is pretty flexible.

> We could describe them as an adaptive templating system : views uses
> each others to build a consistent representation of a dataset, and the
> predicate-based selectors allow to override a view for specific cases.
> So having them handling directly manage the request and return a
> response seems not right to me.

It is possible that you have a superset of the needs that Pyramid addresses with its views. But you can extend the Pyramid view machinery to add in your needs. You would then take advantage of the framework-framework features Pyramid views provide (built-in predicates, custom predicates, security, etc.)

> That said they often generate web-oriented content, and do that
> depending on inputs found in the request. They also need to inject
> resource dependencies into the response, like css of js links.
> Because of that, they hardly can take a single connection do their job.
> We may need to make a distinction between "basic" views and "web" views,
> or define a simple api (some 'context' argument ?) to push relevant
> informations into them.

Right. Also, you can take some of the responsibilities out of these two concepts and inject them from the outside (tween, rendering events, etc.)


More information about the Cubicweb mailing list