[Cubicweb] edition of coupled relations

Christophe de Vienne christophe at unlish.com
Wed May 20 09:25:28 CEST 2015

Hi Sylvain,

For a one shot solution, I would not do anything generic. Something like

- Create an ajax function that returns the right values given a scheme.
This function is easy to write, although very specific to your case.
- Add a javascript function that update the value select depending on
the scheme select using the ajax function
- Call this function at the form loading and on any change of the scheme

We do this (more of less) in Unlish for a form that hide/show some
fields depending on 2 selects.

It is not a beautifully generic solution, but it is fast and efficient,
and as long as there are not too many cases like this in the
application, it remains pretty easy to maintain because it is easy to



Le 20/05/2015 08:08, Sylvain Thénault a écrit :
> Hi there,
> given the following piece of schema:
>   class keyword_scheme(RelationDefinition):
>     subject = 'SEDAKeyword'
>     object = 'ConceptScheme'
>     cardinality = '?*'
>     inlined = True
>   class keyword_value(RelationDefinition):
>     subject = 'SEDAKeyword'
>     object = 'Concept'
>     cardinality = '?*'
>     inlined = True
>     constraints = [RQLConstraint('S seda_keyword_scheme KS, O in_scheme KS')]
> I want a form to edit `SEDAKeyword` where I can edit both relations. As you can
> see fields are related, and AFAIK, there is currently no generic way to get
> proper behaviour in such case (i.e. vocabulary for `keyword_value` being
> properly set depending on `keyword_scheme`, whether in creation or edition of
> the `SEDAKeyword` entity). Am I missing something?
> If not, do you have any idea on the best strategy to solve this? It much
> probably depends on the widgets you use in your form. In my case my default
> choice would be a simple combobox for `keyword_scheme` and a relation widget for
> `keyword_value` (provided by the eponym cube).
> In this configuration, the simplest idea coming to my mind would be to provide
> to the view displaying the relation widget the form values. It could then
> either:
> 1. fetch the edit controller to submit them, get the vocabulary and rollback the
>    transaction
> 2. process them manually and control the generated RQL to skip part of the
>    constraint to get some information from the form data instead of the database
> 1. would probably be simpler to implement, but would cause problems if the form
>    data are yet incorrect wrt schema constraints and other integrity hooks.
> 2. will be hard to implement correctly I'm afraid, but we've already done
> similar things (e.g. using `__linked_to` information)
> Also in the 1. case, form data submission would have to be done on each result page
> display, needing to have form data available when clicking on the navigation
> links.
> All in all, I think I will attempt to get this specific case working by using
> the existing `__linked_to` information support, it should be enough provided
> some litle change to make it works in the case of entity edition as well, not
> only creation.
> Any thoughs / experiences to share?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20150520/596710d0/attachment-0273.sig>

More information about the Cubicweb mailing list