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

Sylvain Thénault sylvain.thenault at logilab.fr
Thu Feb 11 16:45:16 CET 2010


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.

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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: chtemele.py
Type: text/x-python
Size: 6154 bytes
Desc: not available
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20100211/641ca9e9/attachment-0214.py>


More information about the Cubicweb mailing list