[Cubicweb] PYRAMID: render_view

Christophe de Vienne christophe at unlish.com
Wed Jul 9 21:42:39 CEST 2014

Hello Paul,

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

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.

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.

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.

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.



More information about the Cubicweb mailing list