[Cubicweb] About CubicWeb >= 3.7 (potential) refactorings
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??"
> * 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
> * 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
> 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.
> * 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
> * 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
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
Another silly example:
from cubicweb.entity import dc_description, printable_value
from cubicweb.schema import eschema
def dc_description(entity, format='text/plain')
if 'description' in eschema(entity).subjrels:
return printable_value(entity, 'description', format=format)
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:
> * 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`)
> 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
More information about the Cubicweb