[Cubicweb] PYRAMID: render_view
aurelien.campeas at gmail.com
Wed Jul 9 23:06:31 CEST 2014
2014-07-09 21:42 GMT+02:00 Christophe de Vienne <christophe at unlish.com>:
> 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:
> > 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
> > # 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.
Just trying to say the same thing, with almost the same words :)
In CubicWeb, there's a standard (but somewhat replaceable) stack of objects
the handling of the request. They define an "internal world" where many
http direct response and return code handling, form marhsalling, default
html template/layout system,
etc... are boilerplated away.
In this world live "views" and other ui "components" which are specialized
to the various rendering aspects of data structured according to a Yams
Even "controllers" live within the comfortable bounds of this world.
> 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.
Because of composition through ajax ?
> 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.
There's a "pageid" notion that maybe matches your "basic" vs "web" views.
Can you expand ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cubicweb