[Cubicweb] Higher-level API for rtags

Florent Cayré florent at secondweb.fr
Sun Sep 26 14:53:09 CEST 2010

Hi Adrien,

thanks a lot for putting this into an email to the mailing list. I
think a lot of us share your concerns because the CW form system is so
easily configurable that writting your configuration should be made as
easy and readable as possible.

I personally really like your class style way of solving this problem because :

* it naturally keeps form fields + relations of a single form in the same place

* we can use inheritance to avoid repeating ourselves too much when we
have similar forms

Reading your post, I wonder if we should not make form config classes
inherit from AppObject so that they are selectable at run-time :

* this would allow run-time configuration of a single form, based on
DB content for example ; although this could be misused to put things
in the DB that should rather be coded, CW users will probably find
useful use cases (on that comes to my mind is to allow per user
configuration of widgets to have a very customizable interface)

* your form config classes would then simply implement a selector
(very often a combination like "implements('MyEType') &&
match_user_groups('MyUserGroup')" I guess) instead of a plain etype
attribute, and could use properties to dynamically compute the form
configuration (e.g. query the db to know which date time widget a user

Today we can already achieve this with CW, using form selectors and
implementing this in a custom form ; but considering that form
configuration is useful as simpler than forms, a selector system for
config forms would also makes sense I think, but if and only if the
whole is kept simple enough, otherwise people will simply implement a
new form.

To conclude I would say your proposal is interesting and I am +1 for
having this in CW. It makes it even possible to add more features to
it in the future (like the one I propose above) and keep backward
compatibilty, so it sounds very good to me.


2010/9/24 Adrien Di Mascio <adrien.dimascio at logilab.fr>:
> Dear CubicWeb fellows,
> In a client application, being tired of using the lengthy and verbose uicfg
> syntax/API, I ended up with defining higher-level helpers.
> A few examples::
>  # form uicfg helpers
>  hide_fields(etype, fieldnames) # 'hidden' tag
>  set_field_kwargs(etype, fieldname, label=label,
>                   widget=MyWidget())
>  set_fields_order(etype, fieldnames) # 'order' property
>  edit_inline(etype, fieldname) # inlined forms
>  edit_as_attr(etype, rtype) # edit 'rtype' in the 'attr' section
>  # actionxbox uicfg helpers
>  append_to_addmenu(etype, rtypes)
>  remove_from_addmenu(etype, rtypes)
> For "complex" cases, I also tried a class-based declarative API :
> class MyFormConfig(FormConfig):
>    ###### I'd like selectors here ;-) #####
>    etype = 'MyEtype'
>    # hide 'attr1', 'attr5' and 'attr6'
>    hidden = ('attr1', 'attr5', 'attr6')
>    # modify default order
>    field_order = ('attr4', 'attr2', 'attr3')
>    # change default widgets of some relations
>    widgets = dict(
>        attr2=MyWidget(),
>        attr4=MyOtherWidget())
> I think that most of examples below are clear enough and I don't have to
> explain in details what they actually do. You'll find as an attachment the
> underlying implementation for more details (disclaimer: I don't claim the
> API to be absolutely consistent nor exhaustive for the moment).
> My questions then are :
> - Would you like to see this (maybe reworked) go into CW itself ?
> - If yes, which API : the functions-based one ? The FormConfig-based
>  one ? Both ?
> - If, no : do you find the rtags API sexy enough or is it just my API
>  that doesn't fit your brain ;-) ?
> Regards.
> --
> Adrien Di Mascio - LOGILAB, Paris (France).
> Tél:
> Formations - http://www.logilab.fr/formations
> Développements - http://www.logilab.fr/services
> Gestion de connaissances - http://www.cubicweb.org/
> _______________________________________________
> Cubicweb mailing list
> Cubicweb at lists.cubicweb.org
> http://lists.cubicweb.org/mailman/listinfo/cubicweb

Ce message est la propriété de SecondWeb et peut contenir des
informations confidentielles. Si vous n'êtes pas le destinataire
désigné, nous vous remercions de bien vouloir nous en aviser
immédiatement et de nous retourner ce message ou de le détruire, sans
faire un quelconque usage de son contenu, ni le communiquer ou le
diffuser, ni en prendre copie, électronique ou non.

This message is the property of SecondWeb and may contain confidential
information. If you are not the designated recipient, please notify us
immediately and return the message to us or destroy it, without making
any use whatsoever of the contents thereof. Furthermore you should not
forward or copy the message by electronic or other means.

More information about the Cubicweb mailing list