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

Sylvain Thénault sylvain.thenault at logilab.fr
Thu Feb 11 13:39:26 CET 2010


On 11 février 12:48, Aurélien Campeas wrote:
> Le jeudi 11 février 2010 à 12:07 +0100, Sylvain Thénault a écrit :
> > 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)
> 
> +1
 
on the whole thing?
 
> > 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 ?
 
two main things in there:

* I would like to be able to register the same object in different registries
  or with different selectors
* I would like to uniformize what's currently in the boxes/contextnav/components
  registries. One of the most noticeable effect would be great simplication
  of user's preferences.

still in the idea of making things simpler to grasp while more powerful.
 
> > 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 ?
 
I mean a class responsible to handle the logic behind attributes/relations 
descriptors, as well as thing such as fetch_rql, unrelated, and so on...

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

the thing that makes the BlogPrimary view match against AnyPrimaryView for a 
blog entity (while isinstance(blog, AnyEntity).
 
> > * 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 ?)
 
duno.
 
> > 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 ?

there is definitly overlapping. We should first have an idea about how
we want this to work.

To make thinks clearer, when I talk about using ZCA, I'm talking about:
* more Interfaces
* adapters, able to turn an interface into another one

I don't feel like we'll be able to use the zca's provided adapters registry,
but that we will probably need an in-house vregistry based implementation.

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

I don't get it.

 
> What about simple generic functions ? We could write things like:
> 
> from cubicweb.entity import dc_title
> @dc_title.method(Fooentity)
> 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 ...
 
I get it, but imo adapters acheive the same goal and keep oop style 
programming, while with generic function you get down to, herr, functions.
Also with adapter get the additional property that if an adapter adapts
IA to IB, another one IB to IC, you get IA -> IC for free. I'm not sure
how you get such behaviour with generic function. Last but not least, 
I like the idea of interface based programming.
 
> > 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.

that's what the chetemele module I've posted some time ago does:
an api inspired by cwtags w/ auto escaping.

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