Utilisation de la fonction etDisplayValue() dans une expression calculée

4.0
Utilisation de la fonction etDisplayValue() dans une expression calculée
0
Tags: #<Tag:0x00007f64838ab4b8>

#1

Bonjour,

Est-ce qu’il y a un équivalent à la fonction getDisplayValue() à utiliser dans une expression calculée d’un attribut ?

Merci d’avance.
Abed.


#2

Bonjour,

Mettre dans Expression calculée [LABEL:<nom_logique_attribut>]


#3

Merci Nathalie pour cette réponse.
En fait, la fonction LABEL retourne le nom de la liste énuméré (exemple : « Type de bien » pour l’attribut PropertyType) mais ne donne pas la description (ou libellé) associé à la valeur sélectionnée dans la liste comme le ferait un getDisplayValue() dans un hook.
Mon besoin est : si j’ai un attribut énuméré « propertyType » avec le libellé « Type de bien » et qui contient les valeurs suivantes :
1 Habitation
2 Local commercial
Quand on affiche la liste dans un formulaire et qu’on sélectionne « Habitation », c’est le code « 1 » qui est sauvegardé dans la base.
Quand je fais appelle dans l’expression calculée à [VALUE :propertyType], j’obtiens le code « 1 », alors que je voudrais avoir la description (ou le libellé) c’est-à-dire « Habitation ».
Dans un Hook, la fonction getDisplayValue() retourne bien le libellé « Habitation », mais elle ne marche pas dans une expression calculée. D’où ma question :
Il y a-t-il un équivalent à getDisplayValue() à utiliser dans les expressions calculées ?
Merci encore.
Abed.


(David AZOULAY) #4

Non la réponse de @nathalie n’est pas bonne: ObjectField.getDisplayValue() renvoie la traduction de l’item de la liste de valeur d’un champ énuméré (contrairement à ObjectField.getValue() qui renvoie le code de l’item de la liste de valeur. Il n’y a pas de shorthand en [] pour ça, car il n’y a, en général, pas de raison d’utiliser la traduction d’une liste de valeur dans une expression

Cela dit, tout ce qui se fait via les shorthands en [] peut s’ecrire autrement car ce ne sont que des shorthands préprocessés à l’execution en utilisant la variable obj qui correspond à l’objet courant (i.e. le this dans les scripts d’objet)

Ex:
[OBJECTNAME] devient obj.getName()
[VALUE:myField] devient obj.getFieldValue("myField")
etc.

Dans votre cas il faut donc écrire [FIELD:myField].getDisplayValue() ou obj.getField("myField").getDisplayValue()

Attention tout de même aux expressions de contraintes qui sont exécutées à la fois coté client et coté serveur, toutes les APIs n’existent pas nécessairement coté client (typiquement getDisplayValue n’existe pas coté client).


(François Genestin) #5

La fonction sur le front est “displayValue”.
Je vais ajouter l’alias “getDisplayValue” pour la rendre compatible avec les contraintes back.

Idem je vais ajouter les 2 verbes getDate / setDate pour manipuler des objets Date javascript, ce sera plus pratique que des string.


#6

Merci David,
Je n’arrive toujours pas à avoir la traduction de l’item dans l’expression calculée.
Peut-être que je ne devrais pas utiliser la traduction d’une liste de valeur dans une expression, voici ce que je cherche à faire :
Je souhaite faire apparaître sur la « Google Map », certaines informations concernant le bien :

  • Le libellé
  • L’adresse
  • Le prix au m2
  • Et le type du bien qui est un attribut énuméré (« Nabitation », « Local commercial »…)
    propertyType1

Pour le libellé et l’adresse, je prends les attributs existants.
Pour le prix au m2 (propertyPricem2), j’ai créé un attribut non persistant (propertyPricem2D), dans lequel j’ai mis l’expression « "Prix au m2 (€) : " + [VALUE:propertyPricem2] », et ceci marche bien.

Pour le Type de bien (propertyType), j’ai voulu faire pareil en créant un attribut non persistant (propertyTypeD) avec l’expression calculée qui me permet d’afficher la traduction de l’item en essayant par exemple la formule : "Type de bien : " + obj.getField(“propertyType”).getDisplayValue().
propertyType2

propertyType3

Mais le champ reste vide comme le montre la première image.


Peut-être qu’il y a une méthode plus simple.
Merci d’avance.


(David AZOULAY) #7

Sur le principe ça devrait être bon

Déjà, est-ce que le champ calculé est bien valorisé correctement dans le formulaire ? Si oui on verra ensuite ce qui se passe avec ce champ dans le cas particulier de la place map générique


#8

En utilisant la fonction getDisplayValue() :
propertyType5
Dans le formulaire, le champ s’affiche avec la valeur par défaut de l’attribut énuméré (“Habitation”) et non pas la traduction du type du bien en question :
propertyType6
En cliquant sur enregistrer, la valeur devient correcte :
propertyType7
Sur la carte, le champ est toujours vide.


(David AZOULAY) #9

Quid sur la liste ? Une placemap est une liste, si ça ne se calcule pas sur la liste ça ne se calculera pas sur une placemap.


(David AZOULAY) #10

Bon, en regardant de plus près il y a un pb de fond avec les expressions calculées en liste car il manque un binding Rhino sur le record de liste courant (row), on va l’ajouter afin de pouvoir écrire des expressions plus subtiles dans le cas particulier des listes.

Je vous tient au courant


(David AZOULAY) #11

Bon, bilan des courses le binding row a été ajouté au niveau de l’evaluation expressions pour pouvoir gérer le cas des listes et, tant qu’on y était, un nouveau shorthand [DISPLAYVALUE:] a été ajouté.

Du coup une expression du genre [VALUE:myField1] + " " + [DISPLAYVALUE:myField2] fonctionne désormais (et est équivalente à obj.getFieldValue("myField1", row) + " " + obj.getFieldDisplayValue("myField2", row))

Nous ne constatons plus de pb de calcul de champ dans le cas d’un champ non persistant avec une expression du type ci-dessus dans le cas des listes (et placemaps) et des formulaires.


(David AZOULAY) #12

PS : La demo comporte désormais un exemple de ce type (au niveau de l’objet DemoClient):



#13

Merci David, je confirme que ça fonctionne maintenant.


(David AZOULAY) #14

PS: On a mis la doc à jour avc tous les bindings et tags disponibles: https://www.simplicite.io/resources/documentation/01-core/businessobject-code-hooks.md (§ “Expressions”)