[Cubicweb] About CubicWeb >= 3.7 (potential) refactorings
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.
* 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