[Cubicweb] Putting cubes on a Pyramid (was: Understanding _cw)

Christophe de Vienne christophe at unlish.com
Fri May 16 21:46:07 CEST 2014


Le 16/05/2014 20:39, Adrien Di Mascio a écrit :
> Hi Christophe,
>
> On Fri, May 16, 2014 at 3:03 PM, Christophe de Vienne
> <christophe at unlish.com <mailto:christophe at unlish.com>> wrote:
>
>     Le 16/05/2014 14:46, Sylvain Thénault a écrit :
>
>     >> I pretty convinced that pyramid could be the base of cw, and that a
>     >> progressive path exists to get there.
>     >> I want to experiment around this idea and be able to really
>     demonstrate
>     >> the feasibility before putting it forward too much, but if
>     someone is
>     >> interested to dig this subject with me you are very welcome to!
>     > I'm definitly interested but unfortunatly lack time to really
>     help in an other
>     > way than responding to emails on the mailing list. But if the
>     path to reach this
>     > becomes clearer, we may find some resources at Logilab to help.
>
>     That is all I need to invest some time on that. It will not be
>     very soon
>     though, we have a startup to take care of after all :-)
>
>
> This is also something I'd like to try. Do you have something precise
> in mind ? Would it be something "simple" like using pyramid routing +
> "top-level" views that would in turn use a CW repository (RQL + hooks)
> and / or call CW views ?

That is what I have in mind indeed.

> Or do you think of something more tightly integrated, although I have
> no idea what this would look like ?

The general path I foresee is something like that :

1. Basic integration:

    - Plug the cw request api (hopefully splitted in a few meaningful
attributes) on the pyramid request
    - Use the pyramid configurator to produce a dead simple pyramid
application that use a unique view : the current cw request dispatch

At this point, we would have the full cw stack running with pyramid
application as an entry-point :
- Using any pyramid extension is possible.
- We can use pyramid request api (from webob actually) which is, imo,
pretty sane and well documented.
- Dropping twisted would be a nice side-effect is it is not already done
with the wsgi port.

2. Use pyramid plumbing

>From point 1, there is a bunch of things we can drop from cw and replace
with pyramid components :
- authentication
- session management
- url dispatch + convert the CW controllers into pyramid views

3. Use venusian

Like CW, pyramid has a scan phase. The scan is done by a library they
call venusian. It would fullfill the job done currently in CW + give way
more control to the developer who would be able to choose which modules
should be scanned.

4. Rewrite the form system to use deform. I have the impression that we
could implement a colander based editcontroller, and a deform form
generator based on uicfg (we keep this one).

5. convert the last bits of CW that are not views, hooks, orm & rql into
their pyramid equivalent, with the probable exception of the
configuration system (although it would benefit a huge simplification of
the source code by using the now available libraries that do a similar job).


The order of the points 2 to 5 is only a proposition based on how useful
I feel the change would be weighted with the difficulty to do it with
backward compatibility.

At each step of this path, setting proxy apis (marked as deprecated) to
keep backward compatibility *should* be possible, but I can't be 100%
positive about it until we actually try to do it.


Cheers,

Christophe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140516/aba7b5f8/attachment-0101.html>


More information about the Cubicweb mailing list