[Cubicweb] Understanding _cw
aurelien.campeas at gmail.com
Wed May 14 23:40:05 CEST 2014
2014-05-14 22:23 GMT+02:00 Sylvain Thénault <sylvain.thenault at logilab.fr>:
> 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
> 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)
Yes, this categorizes well the bags of methods I listed previously.
One of the nagging problem is that the type discipline of the _cw object
is unsound. Some _cw objects (CubicWebRequestBase instances) provide
only a (small) subset of all the expected (repo/connection) capabilities.
> > 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
> simplification. This is indeed an heritance from the "web fence utopy" I'm
> 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
> local repository, and build a proper API around that. Merging
> and Connection on that purpose, officially granting access to
> 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
Whatever the future holds for _cw, I'd very much like it were re-cast as
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cubicweb