dans une application de gestion des actions de formation, j’ai un besoin utilisateur que je n’ai jamais mis en oeuvre.
ils veulent générer un pdf dont les données sélectionnées dépendraient de valeur saisies par les utilisateurs.
ex : pour une action de formation, ils veulent éditer un pdf contenant des heures suivies par les stagiaires de l’action entre 2 dates saisies.
j’ai bien déclare l’attribut d’action dans l’onglet confirmation de l’action.
dans mon formulaire, il est bien modifiable mais dans la popup de confirmation, il est en lecture seule.
Mais dans mon cas j’utilise un attribut qui ne sert que dans ce contexte. Dans votre cas vous réutilisez un des attributs de votre objet, peut être y a-t-il des hooks ou des contraintes qui jouent sur son caractère modifiable.
Personnellement je ne réutilise jamais les attributs de l’objet en attribut d’action, @Francois tu vois une autre potentielle raison pour que ça pose pb dans le cas décrit ici ?
Les attributs de l’objet sont en lecture seule car font partie de la confirmation de l’action des valeurs saisies : exemple confirmer un montant à payer ou un preview d’un PDF généré avant envoi
Pour avoir un champ en écriture, il faut le créer spécifiquement pour l’action (en tout cas ne pas se servir d’un champ existant de l’objet). Ca deviendra bien un paramètre de l’action, et non de l’objet.
@Francois juste une remarque suite à mes tests (qui par ailleurs confirment ce que tu dis), la valeur par défaut de mon attribut d’action (de type entier) ne semble pas être affichée dans l’input de la popup
Si une action est une methode (Java ou Rhino), vous recevez en arguments les paramètres d’action sous forme de hashmap.
Ensuite dans cette methode d’action vous faites ce que vous voulez de ces paramètres d’action (par exemple vous pouvez valoriser des attributs de votre objet et enregistrer), ex: de la démo:
/** Action: increase stock */
public String increaseStock(Map<String, String> params) {
int q = Tool.parseInt(params.get("demoPrdIncrement"), 0);
if (q > 0) {
ObjectField s = getField("demoPrdStock");
s.setValue(s.getInt(0) + q);
save();
// Log
AppLog.info(getClass(), "increaseStock", "Stock for " + getFieldValue("demoPrdReference") + " is now " + s.getValue(), getGrant());
// User message
return Message.formatSimpleInfo("DEMO_PRD_STOCK_INCREASED:" + s.getValue());
} else
return Message.formatSimpleError("DEMO_PRD_ERR_INCREMENT:" + q);
}
Tout est fait par le front car il n’y a pas d’objet back, les champs paramètres sont envoyés à la méthode sous forme de HashMap puis perdus
En écriture, tous les types d’attributs ne sont pas gérés par ce formulaire simplifié (entier, texte, date, enum… donc pas de document, pas de foreign-key mais on pourrait prévoir de l’implémenter)
En lecture, un champ document est présenté en mode preview
On peut créer un template et juste y mettre des FIELD et des TEXT
Il n’y pas de hooks
pas d’initCreate ce qui doit expliquer que la valeur par défaut n’est pas valorisée mais le front peut le faire si la donnée est dans les metadata du field, je vais regarder
pas de validate, le front vérifie juste qu’un champ obligatoire sera envoyé (pas de contrôle de date par exemple…)
Il convient donc de faire le controle des paramètres envoyés au niveau du code de l’action, qui peut retourner une seule erreur.