Ajout d'un champ de type date dans un script front

Tags: #<Tag:0x00007f2f2afcea58>

Bonjour,

Nous aimerions utiliser un attribut de type date directement dans un script (via un objet externe).

Pouvez-vous nous fournir un exemple pour intégrer correctement ce type de champ ?

Cordialement
Jean-Baptiste

Si je comprends bien vous voulez un datepicker ?

  • Soit vous passez par la couche Simplicité qui affiche un attribut de type date d’un objet métier
$ui.getUIObject('myobject', function(obj) {
   var field = obj.getField("mydate") // { type:app.TYPE_DATE, v: '2020-05-04' ...};
   var df = $ui.view.tools.displayField(ctn, obj, field);
   $("#mydiv").append(df);
}
  • Si c’est juste un champ “input” autonome, autant utiliser le plugin directement avec vos paramètres :

Bonjour,

Suite à la réponse précédente, j’ai ajouté un datePicker un objet externe (notre arbre spécifique).

Cependant je rencontre un problème dont j’ai du mal à trouver la cause.

Lorsque je modifie la date via le calendrier du datePicker, Simplicité semble détecter une modification. Cela a pour conséquence l’ouverture de la pop-up “Voulez-vous enregistrer vos modifications avant de quitter” alors qu’aucune donnée de formulaire n’a été changée.

Est ce qu’il y a un listener global qui capte le changement de la date ? Y a-t-il une méthode front pour les objets externes qui permet de savoir si des changements ont été appliqués (du même type que l’attribut front obj.locals.hasChanged pour les objets métiers).

Merci d’avance pour votre aide.

Jean-Baptiste

Si c’est du code spécifique, il faudrait l’indiquer pour savoir qui positionne le flag hasChanged sur l’objet et responsable de ce popup quand on tente de recharger/quitter la zone.

Un événement change est associé aux éléments select/input/textarea du formulaire quand on passe par les verbes Simplicité displayForm, displayList (en edition)… via les verbes $ui.bindChange ou bindSaveAndQuit.

  • Vous pouvez essayer de le retirer via un .off("change") sur l’input date (attention les éventuelles contraintes front ne seront plus appliquées sur change).
  • Sinon le handler par défaut positionne un flag hasChanged dans les données de l’objet, qui peut être remis à false qq part avant de quitter la div.
  • ou essayer d’ajouter un change qui remet à false :
$("input.mydate").change(function(e) {
  obj.localParameter("hasChanged", false);
});

En y réfléchissant, à mon avis comme l’objet externe est chargé en même temps que le formulaire de l’objet (écran splitté), le bindSaveAndQuit qui passe une fois le formulaire affiché scanne également les inputs contenus dans l’objet externe en leur mettant un “change”.

Essayez d"ajouter la classe selrow à votre input, car elle est ignorée par ce binding automatique.
Sinon il faudra mettre du code front dans le hook form.onload de l’objet pour retirer le change ou en mettre un autre :

$("input.mydate").off("change").change(...);

J’ai ajouté la classe selrow et cela a résolu mon problème.
Merci François.

Ok c’est pas idéal car en fait c’est pour ignorer les check box de sélection en liste, et si un jour on décide mettre un style dessus ça n’ira pas avec ton input…

Il faudrait plutôt qu’on utilise une classe plus intelligible et sans style comme js-ignore-haschanged car ton cas peut se reproduire dans d’autres contextes d’objets intégrés au formulaire sans qu’on veuille provoquer un hasChanged (popup confirmer en cas de sortie sans sauver) + déclencher les contraintes front.

Ce sera fait d’ici demain car c’est pas grand chose.

Bonjour,

Je reviens sur ce post pour avoir des précisions sur l’ajout d’un champ front.
J’ai utilisé la méthode ci-dessus pour insérer des champs de type date dans une pop-up.
Le champ est bien créé mais la couche d’évenement liée au datePicker n’est pas présente.
Dont-on rajouter une instruction ?

Jean-Baptiste

Oui pour certains types de champ (datepicker, select2, tinymce…), le binding des événements doit se faire dans un second temps quand on est sur que l’input est affiché, dans Simplicité le displayField peut travailler sur des div cachés pour aller plus vite avant d’afficher le formulaire.

Dans ces cas particuliers, il faut faire l’init du champ quand le popup est affiché (par exemple dans le onload du dialog view.tools.dialog) comme suit :

var f = $ui.getUIField(ctn, obj, "mydate");
f.ui.init();

f = la définition du champ field + les composants graphiques et accesseurs dans f.ui (init, destroy, visible…)

Attention, il faut aussi penser à appeler le f.ui.destroy() sur le unload du popup ou du conteneur ctn.

Pour le datepicker je crois que ce n’est pas la peine car le picker est dans le dom à côté de l’input, mais pour d’autres composants, il faut nécessairement détruire le composant instancié en mémoire du navigateur, ou sur le body, ou ayant positionné des handlers au niveau document document…