[Cubicweb] annotating divs with rql and vid

Sylvain Thénault sylvain.thenault at logilab.fr
Thu May 24 16:03:58 CEST 2012

On 24 mai 14:51, Nicolas Chauvat wrote:
> Hi List,

> My latest patch to CW is http://www.cubicweb.org/patch/2375100
> As you can see, it adds two data attributes to the main div:
> data-cw_rql and data-cw_vid.
> I contemplate making this the default behaviour. All the divs that are
> generated with rql+vid would be annotated with these two attributes
> and client-side js code could modify the values of these attributes
> before calling a js function similar to _loadDynamicFragment() that
> would take a div as an argument and replace it with the result of the
> query rql+vid.
> That would give us a clear design for client-side manipulation of the
> UI in javascript: look for the data-rql/div attributes, modify if
> needed, then call reloadDiv().
> Facets could be reimplemented on this basis. Instead of modifying
> several links, they would modify only the data-cw_rql attribute of the
> div they affect.
> It would also allow new features like "zoom". Some overlay could
> appear when the mouse enters a div that has data-cw_rql/vid
> attributes. Clicking on the "zoom" icon shown by that overlay would
> make the value of cw_rql the new query.
> Would anyone that knows better than I do the javascript side of
> CubicWeb please comment on the above ?

While I see the benefit of the idea, I would like to warn about the
following things:

* We should be able to have cubicweb sites working without allowing
  arbitrary rql to be given in http request. While this is a desired
  feature of some site, and a powerful aspect of CW, some (corporate/public)
  sites clearly want to disable this ability for obvious security 
  reason. Introducing the above proposal will make this harder if not 

* A lot of views are not only depending on the rql+vid couple, but also
  on additional, arbitrary, arguments. This is somewhat handled by facets
  currently but is imo not really fancy. This later pb could be handled
  by making views more easily self-contained, as recently done (at least
  partially) for table views.

IMO all this should go in a deeper reflexion on how to handle properly
the kind of stateful ui we want. Starting collecting current problems, 
use-cases and technical objectives would definitly be a good start.

Sylvain Thénault, LOGILAB, Paris ( - Toulouse (
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