[Cubicweb] PYRAMID: render_view
Christophe de Vienne
christophe at unlish.com
Thu Jul 10 16:45:41 CEST 2014
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:
>> This part of the discussion probably can be deferred, as it would likely be the last thing you would do.
>>> 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
> 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
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
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.
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
- rethink the cubicweb view API
- use venusian to populate the registry
- make the cubicweb registry based on the pyramid one
... and probably other things I have not seen yet.
More information about the Cubicweb