[Cubicweb] Understanding _cw

aurélien campéas 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
> 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)
>
>
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
> 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.
>
>
Amen :)


> > 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
> thoughs.
>

Whatever the future holds for _cw, I'd very much like it were re-cast as
just 'cw'.

Cheers,
Aurélien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140514/54c1fa1c/attachment-0165.html>


More information about the Cubicweb mailing list