[Cubicweb] Understanding _cw

aurélien campéas aurelien.campeas at gmail.com
Thu May 15 23:45:29 CEST 2014

2014-05-15 21:03 GMT+02:00 Christophe de Vienne <christophe at unlish.com>:

> Le 15/05/2014 09:49, Aurélien Campéas a écrit :
> > On 15/05/2014 09:25, Denis Laxalde wrote:
> >> aurélien campéas a écrit :
> >>> Whatever the future holds for _cw, I'd very much like it were re-cast
> as
> >>> just 'cw'.
> >> At this point, using a descriptive name wouldn't hurt.
> > Yes it would. "cubicweb_god_object" is descriptive but too long.
> It depends : it you want to keep the magic "cw" object, yes it would hurt.

I think such an object has some merits, if not abused or confused.
We don't like the "bad" impredictable magic. We're fixing this.

It is only a "root" object and as such has a *few* *fixed* set of important
high-level objects (and masters of the cubicweb universe ... of discourse).

> But if we split cw, it would not :
> self.appli -> The application, giving access to the vreg and a few
> instance-related api (build_url for example).
> self.cnx -> the connexion to the repo (data access, transaction
> management...)
> self.orm or self.dbsession -> the orm related apis, given that we
> removed 'get_entity' from rset.
> self.request -> the http request, for controllers

I imagine:


cw.cnx ?
cw.req ?

"cnx" and "req" should probably be fed to their workplaces
as standard leftmost parameters in the concerned protocol
entry points imho

> Not all appobjects would have all these attributes :

This is a difficult question. I currently believe we should always
have .config and .reg, a .repo then, and possibly .cnx and .req.

We should find a way to encode this without creating type errors
though. Two ideas:

* noting that there is likely an order of likely appearance in
  the application life cycle:
      config and reg, then repo, then cnx or req

* using "terminator"s (or NullObjects) to avoid AttributeError
  TypeErrors ... i'm unsure this path is safe

* having a hierachy of classes such as CWConfig -> CWApp -> CWRepoApp

> Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140515/0ebb7050/attachment-0165.html>

More information about the Cubicweb mailing list