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

Sylvain Thénault sylvain.thenault at logilab.fr
Wed Feb 10 18:27:51 CET 2010

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 (: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

* 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.

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.


* how does it fit with our 'proximity' computation in the implements selector?

* 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

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

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.

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`)

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