[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:
>>
>>   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.

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

... and probably other things I have not seen yet.

Christophe



More information about the Cubicweb mailing list