[Cubicweb] Understanding _cw
Christophe de Vienne
christophe at unlish.com
Fri May 16 10:05:23 CEST 2014
Le 15/05/2014 23:45, aurélien campéas a écrit :
> 2014-05-15 21:03 GMT+02:00 Christophe de Vienne <christophe at unlish.com
> <mailto: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
> high-level objects (and masters of the cubicweb universe ... of
This description corresponds to what I named "self.appli".
> 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
> 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 ?
I would not.
> "cnx" and "req" should probably be fed to their workplaces
> as standard leftmost parameters in the concerned protocol
> entry points imho
If I understand correctly, you suggest not having a cw.cnx or a cw.req.
Which I totally agree with.
> 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
I don't like it either.
> * having a hierachy of classes such as CWConfig -> CWApp -> CWRepoApp
Please don't. Imo this kind of hierarchy brings complication and
confusion for little benefit, as we never know for sure what we can
access by just reading the attribute name.
The most simple solution is to separate in 2 or 3 attributes/params.
- cw for config, reg and repo, because it is all the instance-wide objects
- cnx when a connection but no request is needed.
- request when a request is needed.
The request object could have a 'cnx' attribute.
We could even have a 'cw' attribute on cnx, removing the need for a cw
argument when calling appobjects.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cubicweb