[Cubicweb] Understanding _cw

Sylvain Thénault sylvain.thenault at logilab.fr
Wed May 14 22:23:35 CEST 2014

On 14 mai 18:42, Aurélien Campéas wrote:
> I believe we should separate db connection from (http) request and
> e.g. learn views to deal with a .req (along with the _cw).

Dunno yet how it should be, but separate of concerns is a must. Here are the
responsability messed in the cw objects that comes to my mind:

* HTTP handling (headers in/out), form params
* URL generation
* ORM entity cache
* repository connection (including session/transaction data)

> Then, let's tackle ClientConnection vs Connection. The separation of
> responsibilities here is quite unclear to me.
> I suspect this may be a remain of the "web fence" utopy (where, in
> principle, a cubicweb "web client" would talk through pyro to a
> cubicweb "repo only" instance). Maybe this is actually needed for the
> pyro/zmqpickle protocols today still (needs to be looked up).
> I see no fundamental reason we cannot flatten ClientConnection onto
> Connection. If we need a RemoteConnection, let's build it and clearly
> state its limits.

This is a problem on his own, that would probably be a good first step toward
simplification. This is indeed an heritance from the "web fence utopy" I'm not
sure why we need this with the new API. Maybe because of the bw compat that
makes a LOT of extra complexity necessary?

Anyway, I'm fine to continue the idea initiated by Pierre-Yves: let's forgot
about remote (pyro/zmq) connections for now, suppose web stuff always have a
local repository, and build a proper API around that. Merging ClientConnection
and Connection on that purpose, officially granting access to hooks/security
control on the web side and all would definitly be a huge gain.

> Then _cw would get rid of all the request stuff (try using dir(_cw) to
> see why it would help) and have a single, consistent API, and be the
> same thing to all people all the time.

At a first glance, I would see the _cw objects as a hub to various objects
handling the various responsabilities listed above. But this needs deeper

Sylvain Thénault, LOGILAB, Paris ( - Toulouse (
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

More information about the Cubicweb mailing list