[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
> >> 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 :
- 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cubicweb