[Cubicweb] CubicWeb 3.6 is (almost) out!

Sylvain Thénault sylvain.thenault at logilab.fr
Thu Feb 11 11:31:02 CET 2010

On 11 février 10:54, Aurélien Campeas wrote:
> Le mercredi 10 février 2010 à 16:57 +0100, Sylvain Thénault a écrit :
> > here is the content of the blog I've just posted:
> > http://www.logilab.org/blogentry/687465
> that's http://www.cubicweb.org/blogentry/687465 actually

oops, right :)
> I've got a couple questions below.
> > 
> > And that's a great news, after several months of development (things starts moved
> > on the begin of august 2009...), it should be available on our debian repositories
> > and ftp site in the next few hours.
> > 
> > So, we can say this release contains a (too) wide set of improvments and
> > refactorings.  I'll take about the most important ones here.
> > 
> > Appobject/Entity classes namespace cleanup
> > -------------------------------------------
> > 
> > First of all, the namespace cleanup... 3.6 is a step toward cleaning the entity
> > classes (hence more generally appobject), which are used for a hell lot of
> > things, making impossible to tell for sure what could be used or not as an
> > attribute or relation name. We decided to reserve names everything that begin
> > with a '_cw' or 'cw_'. A lot of methods have been deprecated to cleanup the
> > base appobject class name space. The remaining methods on entity classes will
> > be removed in future version, by the introduction of an orm for database related
> > methods, 
> What does that mean (the "orm for database relatede methods") ?

currently the cw.entity.Entity class hold a lot of methods and logic which should
be imo in an dedicated class (the ORM), separated from entities classes, which are
high-level abstraction to access data stored in the repository. Having a clear
namespace on this class is important since it defines what one can use or not as
attribute or relation name in his schema. At the end, and with the aid of adapaters,
 we should gain a better design and be able to say: reserved names are '__.*__', 
'_cw.*', 'cw_.*', and that's it.

> > Hooks refactoring
> > -----------------
> > 
> > Hooks are now regular appobjects, with selectors (don't forget to reuse
> > Hook.__select__, remember that !). They should simply implements __call__
> > with no argument (well, only 'self') and will get info previously given as
> > argument as instance attributes, according to the matching event.
> Is this irrevocable (the instance attributes thing) ?

I don't recall the details, but I end up with this solution because at that time
if felt it better suited with the new hook selection process. I don't recall
if there is any actual show-stopper. That change has been largely propagated,
so if I agree it's discussable, I need strong opposition to go backward. But
that's not irrevocable.

Sylvain Thénault                               LOGILAB, Paris (France)
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

More information about the Cubicweb mailing list