initCreate depuis une redirection JS

Support
1

Bonjour,

Nous avons ce code dans une ressource JS associée un objet externe :

fermetures = app.getBusinessObject("xx","xx");
[...]
$ui.displayForm(null, fermetures, app.DEFAULT_ROW_ID, { nav: "add", values:items});

Cependant, il semblerait que le initCreate() ne soit pas déclenché alors que le formulaire s’affiche bien.

Dans d’autres BO nous avons des méthodes java associées à des boutons qui utilisent cette même syntaxe et l’initCreate est bien déclenché. Y’a-t-il une chose supplémentaire à ajouter pour que le code ci dessus s’execute de la même manière que ce code là :

 return javascript(
                "var b = app.getBusinessObject('xx'); " +
                        "$ui.displayForm(null, b, app.DEFAULT_ROW_ID, {nav: 'add'})"
        );
2

Si vous forcez les valeurs du formulaire, il n’y a pas d’appel back.

  • soit vous retirez ce paramètre values pour que le back soit appelé via un “getForCreate”
  • soit vous initialisez cet item correctement, donc via un getForCreate
obj.getForCreate(function(item) {
   // custom values
   item.myfield = "1234";
   $ui.displayForm(null, obj, app.DEFAULT_ROW_ID, { nav:"add", values:item });
});

mais mettre une logique métier en front c’est pas top, autant tout mettre dans l’initCreate / initCopy, et faire uniquement en front :

$ui.displayForm(null, obj, app.DEFAULT_ROW_ID, { nav:"add" });
3

Bonjour,

(On reprend le sujet 1 semaine après car la personne qui s’en occupe ne travaille que le jeudi et vendredi)

Donc vendredi on arrivait a peut près a faire ce qu’on voulait en utilisant le getForCreate.

Les valeurs sont bien passées dans le formulaire dont les champs sont en lecture seule et sont affichées. Cependant, dans le preValidate(), les valeurs sont vide. Lorsque l’on bascule les champs en modifiable, les valeurs sont bien présentes dans le preValidate().
Ma question est donc la suivante : de quelle manière peut on passer les valeurs jusqu’au préValidate et non coté front uniquement ? Mon idée serait d’avoir des champs cachés modifiables mais c’est une solution qui n’est pas du tout élégante.

Voici les screens et le code utilisés actuellement:

Screenshot_25
Screenshot_251625×362 14.3 KB

Screenshot_26
Screenshot_261657×267 8.35 KB

JS (FullCalendar ResourceTimeline):

  dateClick: function(info) {
            	
                    fermetures.getForCreate(function(item){
						
                        item.namDtfmCentreId=info.resource._resource.id;
                        item.namDtfmDateDebut=moment(info.dateStr).format('YYYY-MM-DD');
                        item.namDtfmDateFin=moment(info.dateStr).format('YYYY-MM-DD');
                        item.namDtfmTypeAbsence='Fermeture de centre';
                       
                        $ui.displayForm(null, fermetures, "0", { nav: "add", values:item});
                    });
               },
4

C’est un vieux serpent de mer Simplicité qui révient très souvent…

Un attribut paramétré (statiquement ou dynamiquement) “read only” n’est pas envoyé, c’est normal et parfaitement légitime.

Mais parfois on a besoin d’un attribut “non saisissable” par un utilisateur dans la UI mais quand même envoyé (genre un attribut calculé par du JS coté client).

Cette notion n’a jamais été modélisée. Il y a des manières spécifiques de s’en tirer à coup de JS specifique mais je ne suis pas fan de ce genre d’approches “bricolo” qui risquent potentiellement de finir par ne plus marcher au fil des mises à jour de la plateforme

Bref @Francois, tu pense quoi de cette notion d’attribut non read only mais non saisissable dans la UI ? Une valeur de plus dans la liste ? Un flag à part ? Un rendering ? autre ?

5

Bonjour, serait-il possible d’avoir une réponse avant Jeudi prochain ? Merci d’avance !

6

Bonjour,

L’attribut doit nécessairement être modifiable (au niveau des meta-données) pour être utilisé par le back, sinon ce serait une anomalie grave de sécurité (idem pour un champ non visible ou interdit).

Il faut donc ajouter la propriété readonly uniquement sur le champ de saisie à l’écran à l’ouverture du formulaire, mais surtout le laisser modifiable d’un point de vue logique (donc pas utiliser un f.setUpdatable(false) en back, ou son équivalant en front javascript f.updatable=false).

Dans le SCRIPT front de l’objet, utiliser le hook form.onload pour changer l’affichage de l’input associé au champ :

var f = $ui.getUIField(ctn, obj, "myfield", index);
if (f && f.ui) 
   $(f.ui.input).prop("readonly", true);

Le field restera modifiable d’un point vue métier, mais juste non saisissable à l’écran.

@david on pourrait effectivement ajouter cette notion dans méta-modèle mais avec un gros warning de sécurité car ce n’est pas la bonne approche pour rendre un champ non modifiable. La contrainte front est une autre piste mais pas plus pratique qu’une ligne de code. Je vois plus quelque chose dans le template de l’objet / via le template editor pour ajouter des indications front uniquement au dessus des propriétés de l’attribut :

<div class="field" data-field="myfield" data-readonly="true"/>

Que le front pourra interpréter tout seul comme les 3 lignes de code ci-dessus (et même si le champ n’est pas un simple input).

7

@Francois, comme discuté j’ai fait un test en 5.1 avec une contrainte “front” qui rend “readonly” (donc coté client) un attribut modifiable coté serveur et ça marche : l’attribut est bien non saisissable mais sa valeur (modifiée coté client) est bien transmise au serveur. De mémoire ça ne marchait pas mais visiblement ça marche désormais.

8

Nickel, donc 2 possibilités pour répondre à ce besoin.