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