[Cubicweb] Understanding _cw

Christophe de Vienne christophe at unlish.com
Fri May 16 14:33:32 CEST 2014


Le 16/05/2014 14:15, Sylvain Thénault a écrit :
> On 16 mai 13:57, Christophe de Vienne wrote:
>> Le 16/05/2014 10:22, Sylvain Thénault a écrit :
>>> On 16 mai 10:05, Christophe de Vienne wrote:
>>>> 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.
>>> sounds good, though I would rephrase the two last points: 
>>> - cnx when a connection to the repo is established
>>> - request when the originator is an HTTP request
>>>
>>> Take care that in some case, we'll have to process an HTTP request without a
>>> connection being established (eg register/lost password form for site where
>>> anonymous are not allowed).
>> A request exists before it is linked to a cnx, and even any repo or
>> config (at the very early stage of handling it).
> Yes.
>  
>> The case of the views remains unclear to me. A cnx feels not enough (am
>> I wrong on that ?), and a request way too much : we should be able to
>> use views outside the handling of http requests.
> Yes again.
>
> Did I say something that contradict those two points? 

No, I just wanted to be explicit to make sure we are saying the same thing.


>>>> 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.
>>> This is not clear to me. Currently the cw is an argument mostly because of it
>>> being the request object.
>> Well, removing the cw argument and have it as an attribute on request
>> would make the api more pyramid-like.
> ok, fine. I fully agree that everything that allows cubicweb to look similar to
> other popular framework such as pyramid is a good step forward by easing its
> adoption. Ultimatly, having cubicweb specificities on top of a generic web
> framework as pyramid would be awesome (IMO).

Well, I am currently working a bit with pyramid (for which I help a
client to build an openerp frontend, with lots form autogeneration,
non-trivial acls, resource traversal _and_ url dispatch etc), while
getting my hand on the cw internals thanks to the oauth and wsme cubes.

And it strikes me everytime how similar the two frameworks are in some
areas, which are the ones CW has little added value (I have in mind the
http request handling & dispatch, url resolver, authentication,
interface with controllers, source scan for registering objects, auto
reload...).
The things CW is good at (rql, hooks, orm & views) could totally fit on
top of these basic features.

I pretty convinced that pyramid could be the base of cw, and that a
progressive path exists to get there.
I want to experiment around this idea and be able to really demonstrate
the feasibility before putting it forward too much, but if someone is
interested to dig this subject with me you are very welcome to!


Christophe



More information about the Cubicweb mailing list