Comment générer un pdf selon des critères utilisateur

Comment générer un pdf selon des critères utilisateur
0
Tags: #<Tag:0x00007f394e157870>

Bonjour,

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.

est-ce-qu’en utilisant un externe ?

Ca peut se mettre en place avec une action avec paramètres.

C’est la même chose que ce qui a été discuté dans ce topic: Template Excel qui contient des valeurs saisies par utilisateur

oui en fouillant, c’est ce que j’ai trouvé.

je teste mais pour l’instant, l’attribut apparatit bien dans la fenêtre mais n’est pas modifiable

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.

Je ne constate pas de pb:

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 ?

j’ai créé des attributs pour le contexte aussi.
je les ai affiché dans le formulaire justement pour voir si les hooks de mon objet posaient un pb

  • 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

merci @francois ça fonctionne.

dernière question relative au ticket dont @davidfait référence :
"La méthode back de cette action me permet de valoriser un paramètres d’objet. "

on parle bien de méthode déclarée dans l’action :


et scriptée dans l’objet métier ?

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);
	}

Oui c’est assez basique :

  • 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.