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

Aurélien Campeas aurelien.campeas at logilab.fr
Thu Feb 11 17:16:22 CET 2010


Le jeudi 11 février 2010 à 16:45 +0100, Sylvain Thénault a écrit :
> On 11 février 13:49, Aurélien Campeas wrote:
> > Le jeudi 11 février 2010 à 13:39 +0100, Sylvain Thénault a écrit :
> > > > > 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
> > 
> > can you give a concrete use case for this ?
> 
> one easy use case: I've view and an action to this view. I would like to have both
> in the same class, this seems natural. Other use cases I've in mind will probably
> go away with the proposed unification. But I think we'll find some as the idea
> propagate. Or not, and we won't touch the statut-quo.

oh it's a bit like when I wanted to collapse forms and controllers to
have methods of either on the same class ? I can see that ...

> 
> > > * 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.
> > 
> > question: what's the true point behind the vregistry namespaces (views,
> > forms, components, etc.) ?
> > 
> > I've seen it as a perf. hack but I may be mistaken.
> 
> perfs, and interfaces / expected usage of objects found in there.

hmm, a classification scheme ?

> 
> > > > > 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.
> > > 
> > 
> > could you post this here or in some accessible place ?
> 
> as attachment of this mail. 
> 

thanks

autoescaping: yes, but I do not see the bw compat thing there
is it actually in ?




More information about the Cubicweb mailing list