[Cubicweb] [CubicWeb / discussion] Improving uicfg

Aurélien Campéas aurelien.campeas at logilab.fr
Thu Dec 19 11:49:33 CET 2013


On 13/12/2013 08:08, Adrien Di Mascio wrote:
> 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'm not sure I really understood the OP demand.
As I see it, this can be done today with a custom view, e.g.::

 pvdc.tag_subject_of(('Subject', 'relation', '*'), {'vid': 'customvid'})


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

Imho the primary views API does/provides too much... The distinction
between attributes/relations/.... sections is quite arbitrary and is
only a concern for the historic "generic" base views, which partly
follows the distinction made in the automatic entity forms wrt
"attributes" and "relations" sections, that exists more for technical
reasons than anything else (and which the `relationwidget` cube would
like to make obsolete).

It basically defines a three-sections "layout" with impact in both the
code (with render_entity_{attributes|relations|....} methods) and the
uicfg pvs section tags.

While it is possible to comfortably live within this paradigm, at
least once familiarized with it (e.g. for GDF we keep the basic
attributes/relations layout, but with different roles), it already
provides too many "hooks" for a basic entity view.

Of course one always can redefine wholesale the python code from
e.g. the .render_entity or even .entity_call entry points. But then
the developper may find herself asking how much of the uicfg bagage to
keep supporting and wind up reimplementing all of the pv logic (with a
specific interpretation of what it should do).

So we might want to go in the following direction:

* keep the default primary view a thing that uses schema introspection
  to build its output

* either get rid of the section idea, or make it extensible
  (e.g. allow people to easily declare fancy layouts and their
  matching uicfg "section")

* allow to specify pseudo attributes (e.g. an entity.nb_votes ppty) to
  be processed by the view (e.g. pvs.virtual_attribute('Ticket',
  'nb_votes')) -- but I expect coming remarks about doing it now with
  a schema-based computed attribute :) even though I believe there is
  room for both ways

and probably some more that I still haven't thought of right now.

Regards,
Aurélien.








More information about the Cubicweb mailing list