[Cubicweb] Cubicweb Digest, Vol 58, Issue 11

Vladimir Popescu vladimir.popescu at logilab.fr
Tue Dec 17 16:31:10 CET 2013


Hi,

On 13/12/2013 12:00, cubicweb-request at lists.cubicweb.org wrote:
> ------------------------------ Message: 7 Date: Fri, 13 Dec 2013
> 08:08:45 +0100 From: Adrien Di Mascio <adrien.dimascio at logilab.fr> To:
> cubicweb at lists.cubicweb.org Subject: Re: [Cubicweb] [CubicWeb /
> discussion] Improving uicfg Message-ID: <52AAB27D.8030608 at logilab.fr>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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.

Yes, good point, so we would have something like:

pvs.add_to(('Subject', 'my_attribute'), 'attributes')
pvdc.tag_attribute(('Subject', 'my_attribute'), {'vid': '...', 'rql':
'DISTINCT Any X WHERE ...'}) ?

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

That is what we currently do / did (extend the PrimaryView and override
render_entity_attributes, etc).
The purpose of this discussion would be just to see to what extent we
could use uicfg for such
customization and to what extent we should keep extending the PrimaryView.



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

Best,
Vladimir



More information about the Cubicweb mailing list