[Cubicweb] About CubicWeb >= 3.7 (potential) refactorings

Aurélien Campeas aurelien.campeas at logilab.fr
Thu Feb 11 12:48:01 CET 2010

Le jeudi 11 février 2010 à 12:07 +0100, Sylvain Thénault a écrit :
> Now that cubicweb 3.6 is out, we can brave and think about the future :)
> As I'm begining to plan what will go in the 3.7 release, I though I should
> talk about what *refactoring* I would like to have in a near future, which
> will imo enhance the developper experience. As I don't want to do the same
> error as with the 3.6 release, we won't put them all in a 3.7!
> So I want to discuss this with you guys. Once you've read the refactorings
> described below, could you answer to the following questions:
> * What do you think about the proposed refactorings?
> * Do you have other one in minds that should be listed here?
> * Would you like to work on one of these?
> * If you add to pick one of them, which one would you choose?
> Make unsafe_execute the default on session (:eid:`344874`)
> ==========================================================
> all code in hooks are executed without security checking. Once we state that,
> much more clear interface, no needs for one to ask himself "should I use
> execute or unsafe_execute??"
> Check:
> * do we need same 'safe_execute' method? probably, needs check for such usage
>   in cw (tests should detect this)


> Unify actions/box/components and maybe others 'type' of appobjects 
> (:eid:`468093`)
> ==================================================================================
> * drop the 'component' / 'contextual component' distinction
> * in a perfect world, also unify with box, and one can display our new
>   "universal components" as a box, global / contextual component according
>   to context set in his cw properties
> * allowing registration of an object in multiple registry
>   -> eg implements IAction and IView and get in the same class
>      the view and the action leading to the view

I don't get this. Can you explain a bit more ?

> * stops making actions configurable via cw properties (#XXX)
> Introduce an ORM to cleanup Entity class (:eid:`615240`)
> ========================================================
> We'll have to do this at some point. Was expected in 3.6 but... That doesn't
> seems that in a hurry though.

an ORM ... do you actually mean a specific namespace for methods ?

> Introduce adapters to cleanup AnyEntity and other type specific classes 
> (:eid:`482289`)
> =======================================================================================
> To finally cleanup the entity classes namespace. Would avoid mixins trick
> (use case: turn the TreeMixIn into a base adapter). Finally, allows to
> provide much more clear / reusable code.
> Check:
> * how does it fit with our 'proximity' computation in the implements selector?

can you expand on this ? (I have no idea of what the 'proximity
computation' may be)

> * can we rely of the adapters registry provided by zca or do we need a custom
>   one?
>   * perf. impacts if for instance dc_* methods are moved to an adapter

(perf: wouldn't the slight cost be in the noise wrt all the things a web
request entails ?)

> IMO, it should be introduced slowly (but on the first occasion).

We should begin, I feel, to explain what an adapter is, and what problem
it solves. Same for ZCA (the litterature on ZCA I have read 'till now is
not cristal clear).

For namespaces/registries, we already have the vregistry thing. Isn't
ZCA another way to provide the same kind of service ?

If Entity namespace pollution is the main pb. to solve, couldn't reusing
the vregistry be a solution ? (as in: it would host Entity methods)
But the score-based dispatch used there maye not be fit.

What about simple generic functions ? We could write things like:

from cubicweb.entity import dc_title
def dc_title(entity):
    return entity.name

Here dc_title has been turned into a lightweight dispatcher object that
needs not to live in a global registry but in plain python modules. In
the example above we just added a concrete implementation that applies
to subclasses of Fooentity.

Reusing existing gf libs, one would get multiple dispatch as a
(worthwhile) bonus.

Another silly example: 

from cubicweb.entity import dc_description, printable_value
from cubicweb.schema import eschema
@dc_description.method(Fooentity, basestring)
def dc_description(entity, format='text/plain')
    if 'description' in eschema(entity).subjrels:
        return printable_value(entity, 'description', format=format)
    return u''

I hope you get the idea ...

> Use lxml or similar to ease/improve xml/html generation 
> (:eid:`1218`, :eid:`577964`, :eid:`459771`)
> ===================================================================================================
> wide topic... The hotest point being its introduction in the cubicweb
> view system : we should be able to manipulate DOM trees while keeping
> backward compatibility with 'string' views.
> Alain should provides some input soon about the pros & cons of lxml
> vs other libraries.

For the record, I've built a small backwards-compatible lib to ease html
generation (https://www.logilab.net/cwo/project/cwtags). It is now used
mostly in private cubes, except cubicweb-document, and works well for us
(I think :)).

It does not tackle the pb. of autoescaping yet because I'm not sure how
to do that in a backward-compatible, sane and non-performance hurting
way. But it is planned somehow.

Please have a look at the API. It could be made to use lxml if we want

A slightly nicer/cleaner API is shown there:

> Javascript / Css resources management refactoring
> =================================================
> * the external_resources file
> * substitution in js/css files
> * minification (:eid:`438219`)
> * see existing generation framework
> We definitly need better than what we have on this topic... Begin by writing
> a ticket resuming what we want & all (or find an existant one, didn't find it
> in a quick search, beside the one mentioned above)
> Schema definition files improvment (http://www.logilab.org/ticket/9933)
> =======================================================================
> remove ObjectRelation, split cardinality, ... Can be improved without the
> amount of work necessary for the initial proposal.
> URL handling (:eid:`345139`)
> ============================
> Later...
> -- 
> 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
> _______________________________________________
> Cubicweb mailing list
> Cubicweb at lists.cubicweb.org
> http://lists.cubicweb.org/mailman/listinfo/cubicweb

More information about the Cubicweb mailing list