Pas besoin d’écrire du code pour ce genre de besoin.
Merci de systématiquement expliquer votre besoin fonctionnel avant de poser une question technique fermée car souvent la vraie bonne réponse à votre question est autre chose, comme ici.
Je sais pas, mais mon besoin c’est que la première liste est remplie par défaut, par contre la deuxième elle vide et elle dépend de la première pour être rempli.
Vous vous moquez de moi ! Je viens de vous expliquer en détail qu’il n’y a pas besoins de code pour répondre à ce type de besoin.
Vous lisez mes réponses ???
Comme je vous l’ai dit dans une réponse précédente : regardez le paramétrage de la Demo, il y a un exemple qui fait exactement ce que vous voulez faire. Transposez le dans votre cas.
Dans ce cas expliquez moi votre besoin de manière plus précise car je ne comprends pas en quoi le mécanisme standard des listes liées ne répond pas à votre besoin.
Voilà en video l’exemple de la démo dont je parle:
Bonjour,
Je reviens vers vous pour vous expliquer mon besoin en détails, j’ai une liste « Calculation method » qui contient : ‘GTI_OBJECT_DELAY, GTI_OBJECT_ECART, GTR_OBJECT_DELAY, GTR_OBJECT_ECART, GTI_GLOBAL, GTR_GLOBAL’ et une autre liste « Kpi » qui est vide.
Lorsque je choisis ‘GTI_GLOBAL ‘ ou ‘GTR_GLOBAL’, je récupère tous les noms indicateurs du type ‘GTI_OBJECT_DELAY, GTI_OBJECT_ECART, GTR_OBJECT_DELAY, GTR_OBJECT_ECART’ sur la liste « Kpi ».
NB: La liste« Kpi » par défaut est vide.
J’espère que cette fois j’ai bien exprimé mon besoin, et merci d’avance.
OK je continue à penser que votre besoin n’est qu’un cas particulier du mécanismes standard des listes liées.
Avez vous essayé de mettre ça en place de cette manière (en vous inspirant du cas que je vous ai indiqué sur la démo) ?
Sinon, avec une contrainte vous pouvez aussi rendre dynamiquement visible/invisible votre attribut “Kpi” en fonction de la valeur de votre attribut “Calculation method”. Peut être que dans votre cas particulier cette approche est plus adaptée.
On a ajouté un exemple de contrainte de ce type sur la démo :
Pour rappel vous pouvez vous (ré)installer la démo à jour via ces URLs:
Utilisez des listes liées : créez toutes les listes mère/filles unitairement, et assemblez-les dans “Listes liées” en vous servant des exemples cités par David.
ou alors faites une contrainte Front avec en expression un test de la valeur du champ déclencheur, avec 1 impact de type Liste de valeurs sur l’attribut lié avec en valeur le nom de la liste à charger.
au delà, si vous n’y parvenez pas, il vous faudra suivre un formation de base. Ce forum n’est pas un centre de formation initial.
Et peut être aussi que vos “listes de valeur” sont plutôt en fait des objets métier avec des link mappings et/ou des contraintes pour les “lier” de manière cohérente. Etc.
@Francois a raison: ce forum ne peut pas se substituer à une formation, surtout si on parle de patterns de paramétrage relativement “avancés”. La preuve c’est cet échange où depuis le début on vous indique que votre besoin est sans doute à implémenter sous forme de liste liée mais que vous ne comprenez visiblement pas bien de quoi on parle. Or cette notion de liste liée est abordée lors des formations…
@david j’ai déjà utilisé les listes liées “Link mapping” lors de la formation “training”, et j’ai bien compris leur rôle.
Dans tous les cas je vous remercie pour votre intérêt.
Si les valeurs possibles de vos 2 listes sont déterminées à l’avance et liées entre elles via des règles immuables alors c’est clairement des linked lists.
Sinon, si les valeurs possibles pour l’attribut Kpi sont le résultat dynamique d’une recherche complexe en base dont les critères de filtrage ne sont pas uniquement la valeur de l’attribut Calculation method alors votre attribut Kpi n’est peut être pas un attribut de type liste de valeur : ça peut être par exemple une référence filtrée (link mapping) vers un objet métier ad hoc, un data mapping, etc.
Ce que je n’arrive pas à comprendre dans vos explications c’est la nature et la variabilité des valeurs possibles pour Kpi…