[Cubicweb] [CubicWeb / discussion] Improving uicfg
Adrien Di Mascio
adrien.dimascio at logilab.fr
Fri Dec 13 08:08:45 CET 2013
Hi,
Le 12/12/2013 19:36, Vladimir Popescu a écrit :
> 1. Be able to add RQL-computed rsets, e.g.
> pvdc.add_to(('Subject', 'attributes'),
> {'rql': 'DISTINCT Any X WHERE ...'
> '<restrictions on X>...',
> 'vid': '...', 'label': '...'}),
> where 'X' is implicitly the Subject. Here, we would use
> 'attributes' or 'relations', depending on the nature of
> the computed rset.
I like the idea. I would however let the PrimaryViewSectionRelationTags
(pvs) handle the dispatching on relations / attributes sections to keep
things consistent.
> 2. Be able to add a callback which generates e.g. custom HTML and /
> or navigates through the paths between entities. For example:
>
> pvdc.add_to(('Subject', 'attributes'),
> {'callback': 'foo', 'vid': '...', ....})
>
> def foo(w, entity):
> displayable_ent = entity.relation[0].attribute
> w(... displayable_ent ...)
This seems indeed the most generic approach since we would be able to
implement business rules, "show if / else", etc.
> I would like to discuss on the opportunity of
> implementing these improvements / tackling these issues.
> A start could be to decide which tickets to add
> to the CW project.
That said ... I don't know if we're not trying too hard to find some
nice declarative ways of handling complex cases. IMHO, we should be able
to handle such cases by simply extending ``PrimaryView`` and overriding
approriate methods. If we're not able to do this (i.e. without copying a
whole method just to insert one line of code in the middle), then it
probably means that the ``PrimaryView`` API is badly designed.
Cheers,
--
Adrien Di Mascio - LOGILAB, Paris (France).
Tél: 01.45.32.03.12
Formations - http://www.logilab.fr/formations
Développements - http://www.logilab.fr/services
Gestion de connaissances - http://www.cubicweb.org/
More information about the Cubicweb
mailing list