Surchage de message

Bonjour,

je voudrais n’avoir qu’un seul message à la place de la liste des champs obligatoires

Je pensais faire cela dans le postValidate mais lorque les champs sont obligatoires le message que je construit dans le postValidate ou prevalidate n’est pas pris en compte. est ce possible de le faire sans modifier la configuration des champs ?
Merci d’avance

Thierry

Si vous remontez des messages d’erreur au preValidate cela s’arrête à ce niveau, vous êtes avant le validate générique qui n’est donc pas exécuté

Au postValidate vous êtes après le validate vos message (erreur ou warning) s’ajoutent donc aux éventuels messages issus du validate (ils ne les remplacent pas)

C’est peut être lié à mon problème sur le changement de configuration (j’ai crée un ticket) mais j’ai
fait un test en forçant un message

	@Override
	public List<String> preValidate() {
		List<String> msgs = new ArrayList<>();
		
		AppLog.info(LadDossierAct.class, "preValidate", "Nom " + getFieldValue(FIELD_ACT_NOM) , null);
	
		if (!com.simplicite.commons.ladnext.LadUtils.isFieldValueOui(getFieldValue(FIELD_ACT_DEMANDEURCHEFFOYER))){
			msgs.add(Message.formatInfo("Données obligatoires", "Veuillez renseigner l'onglet chef de foyer fiscal", null));
			//if (LISTCODE_CIVILITE_VEUILLEZ_SELECTIONNER.equals(getFieldValue(FIELD_ACT_CFF_CIVILITE)) ||
			//	getFieldValue(FIELD_ACT_NOM).isEmpty()) {
			//	msgs.add(Message.formatInfo("Données obligatoires", MSG_INF_FICHE_IDENTITE_CHEF_FOYER_FISCAL, "fieldName"));
			//}
		}
		AppLog.info(LadDossierAct.class, "preValidate", "msgs.size " + msgs.size() , null);
		return msgs;
	}

mais je ne vois que les messages de champs obligatoires de la première copie d’écran

Vous ne remontez visiblement qu’un message d’information dans votre preValidate => seuls les messages d’erreur sont bloquants (les message d’information ou d’avertissement sont passants)

RECTIFICATIF: j’ai vérifié ce que j’ai dit précédement est faux, les messages du preValidate ne sont pas bloquants quels que soient leur niveau (erreur, warning, info), ex:

En mettant msgs.add(Message.formatError(“Données obligatoires”, “Veuillez renseigner l’onglet chef de foyer fiscal”, null)); cela l’ajoute aux autres et ils ne sont donc pas bloquant

Oui cf. mon rectificatif ci-dessus

Dans votre cas vous voulez ne pas faire faire la validation standard mais une validation custom => mettez vos attributs non obligatoire dans le preValidate (quite à les remettre obligatoire dans le postValidate et/ou dans les initXxx).

@Francois j’avais le souvenir que les messages d’erreur du preValidate étaient bloquants, c’est une erreur de ma part ou c’est un changement “récent” / voulu ?

J’aurais bien voulu faire la validation standard d’autant que c’est un contrôle obligatoire oui/non mais je voulais surcharger le message, typiquement le caractère bloquant du preValidate m’aurait arranger s’il permettait de conserver le caractère obligatoire des champs mais de pouvoir gérer le message

Attendons la réponse de @Francois

PS: une solution de “cochon” est de surcharger le validate, genre:

@Override
public List<String> validate(boolean onlyErrors)
{
	if (getGrant().isUIEndpoint() && ...) { // ne faire ça que sur la UI et si ...
		List<String> msgs = new ArrayList<String>();
		msgs.add(Message.formatSimpleError("Mon erreur custom"));
		return msgs;
	}
	super.validate(onlyErrors);
}

Personnellement je m’interdit de faire ce genre de choses.

Le preValidate n’a jamais été bloquant, il sert à préparer les données pour le validate des champs :

  • champs (re)calculés ou (re)formatés ou valeur par défaut
  • changer le caractère obligatoire pour bypasser le controle et le remettre au postValidate
  • Depuis les hooks en Java on peut bien surcharger le validate directement (en faisant attention d’appeler le super.validate à un moment donné). Ca n’a rien de risqué c’est tout l’intérêt de l’héritage Java.

Ces messages ne sont pas là pour être retirés en terme d’UX. Sinon mettez juste une regle CSS pour rendre invisible les div > 3 dans les STYLES de l’objet (montrer que 3 erreurs à l’utilisateur).

C’est plutôt l’objet/écran ou le processus de saisie UX qui est à revoir si la UI est amenée à avoir 50 erreurs.

  • Le erreurs liées à un champ sont cliquables pour mettre le focus directement sur le champ, et ce notamment s’il est dans un onglet caché. Sinon l’utilisateur ne peut pas comprendre qu’il y a des erreurs cachées (tabs ou scroll vertical).
  • Si vous remplacez cet entête par un message “Vous avez des erreurs” l’utilisateur devra tout scroller et ouvrir tous les tabs…
  • Si vous avez 50 champs obligatoires pour une raison métier, mettez les de préférence ensemble/à proximité pour que l’utilisateur n’arrive jamais à avoir 50 erreurs. La petite étoile * lui permet de vite repérer ce qui est obligatoire
  • Un autre design-pattern est de ne saisir que qq champs obligatoire en début de processus ou en création (la clé fonctionnelle, les références…) et de rendre les autres champs obligatoirse qu’au fur et à mesure qu’on avance dans le processus. Ou juste limiter les nb de champs obligatoires à la création avec un test de isNew() dans une contrainte.

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.