Discussion :

[lastrecrue]

Bonjour

j'ai un champs de saisi h:inputtext avec valuechangelistener qui se déclenche correctement sauf si j'efface le champs de saisie.

avez vous une idée sur comment détourner ce problème?

j'utilise rich face comme jeux de composant.

[tchize_]

les champs vides échappent à toute la phase de validation jsf, phase durant laquelle, je suppose, le valuechangelistener est déclenché.

[lastrecrue]

ca veux dire que je ne peut pas intercepter le fait que ca le champs soit vide ??? ou bien je pourrais faire un converter ??? si non je veux bien avoir d'autre idées.

[romaintaz]

Cela se passe durant la phase de validation, et je me demande si la théorie de tchize_ ne serait pas la bonne explication au problème.

A confirmer en passant par un mode de débug je pense...

[romaintaz]

Tu peux nous montrer ton code ? Quelle version de JSF utilises tu ?

Je viens de réaliser le test, avec ce code JSF :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<h:inputText value="#{bean.foo}" valueChangeListener="#{bean.hasChanged}"/>

Ma méthode hasChanged(ValueChangeEvent evt) ne faisant que logguer son appel + les valeurs de l'input. Voici les logs :

Premier appel, avec remplissage du champ avec une valeur :

BEFORE PHASE [RESTORE_VIEW 1]
AFTER PHASE [RESTORE_VIEW 1]
BEFORE PHASE [APPLY_REQUEST_VALUES 2]
AFTER PHASE [APPLY_REQUEST_VALUES 2]
BEFORE PHASE [PROCESS_VALIDATIONS 3]
HAS BEEN CHANGED !!
null ==> coucou
AFTER PHASE [PROCESS_VALIDATIONS 3]
BEFORE PHASE [UPDATE_MODEL_VALUES 4]
AFTER PHASE [UPDATE_MODEL_VALUES 4]
BEFORE PHASE [INVOKE_APPLICATION 5]
AFTER PHASE [INVOKE_APPLICATION 5]
BEFORE PHASE [RENDER_RESPONSE 6]

Puis suppression du contenu du champ, puis soumission du formulaire :

BEFORE PHASE [RESTORE_VIEW 1]
AFTER PHASE [RESTORE_VIEW 1]
BEFORE PHASE [APPLY_REQUEST_VALUES 2]
AFTER PHASE [APPLY_REQUEST_VALUES 2]
BEFORE PHASE [PROCESS_VALIDATIONS 3]
HAS BEEN CHANGED !!
coucou ==>
AFTER PHASE [PROCESS_VALIDATIONS 3]
BEFORE PHASE [UPDATE_MODEL_VALUES 4]
AFTER PHASE [UPDATE_MODEL_VALUES 4]
BEFORE PHASE [INVOKE_APPLICATION 5]
AFTER PHASE [INVOKE_APPLICATION 5]
BEFORE PHASE [RENDER_RESPONSE 6]
AFTER PHASE [RENDER_RESPONSE 6]

Je suis sur JSF 1.2_07-b03-FCS.

[tchize_]

Cela se passe durant la phase de validation, et je me demande si la théorie de tchize_ ne serait pas la bonne explication au problème.

Comme dit (ou sous entendu) je ne sais pas exactement comment est géré le value changed. Mais ce qui est certains, c'est que dans les specs:

un champ vide n'est pas validé, seul le critère required=true est checké dessus
un champ "non soumis" (retiré par javascript ou par bidouille de l'utilisateur) échappe à toute validation, c'est comme si le composant n'existait pas (pas de décodage, pas de conversion, pas de validation, par d'appel au setter du bean). Il est d'ailleurs fortement recommandé de ne pas utiliser la validation JSF pour les validations de sécurité, juste comme aide à l'utilisateur. (il faut toujours faire une validation plus profonde à l'intérieur du bean avant de stocker en DB quand c'est nécessaire)

[lastrecrue]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<h:inputText value="#{bean.foo}" valueChangeListener="#{bean.hasChanged}" requiered="true"/>
<h:commandButton action="#{bean.fermer}" value="fermer" immediat="true" />

si on mais dans foo une valeur au chargement du bean , on supprime cette valeur et on clic sur valider le hasChanger ne se déclenche pas sauf si on change sans tout effacer.

[lastrecrue]

Comme dit (ou sous entendu) je ne sais pas exactement comment est géré le value changed. Mais ce qui est certains, c'est que dans les specs:

un champ vide n'est pas validé, seul le critère required=true est checké dessus
un champ "non soumis" (retiré par javascript ou par bidouille de l'utilisateur) échappe à toute validation, c'est comme si le composant n'existait pas (pas de décodage, pas de conversion, pas de validation, par d'appel au setter du bean). Il est d'ailleurs fortement recommandé de ne pas utiliser la validation JSF pour les validations de sécurité, juste comme aide à l'utilisateur. (il faut toujours faire une validation plus profonde à l'intérieur du bean avant de stocker en DB quand c'est nécessaire)

est ce possible d'avoir la référence de ton affirmation, le paragraphe de la spe de jsf qui dis ca ...
merci d'avance.

[tchize_]

dans la spec:
"The render-independent property required is a shorthand for the function of a “required” validator.". Donc mettre isRequired à true, c'est ajouter un validator.

et dans la java doc, uinput.validate(), on trouve

Perform the following algorithm to validate the local value of this UIInput.

* Retrieve the submitted value with getSubmittedValue(). If this returns null, exit without further processing. (This indicates that no value was submitted for this component.)
* If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and getSubmittedValue() returns a zero-length String call setSubmittedValue(java.lang.Object), passing null as the argument and continue processing using null as the current submitted value.# Convert the submitted value into a "local value" of the appropriate data type by calling getConvertedValue(javax.faces.context.FacesContext, java.lang.Object).
* Validate the property by calling validateValue(javax.faces.context.FacesContext, java.lang.Object).
* If the valid property of this component is still true, retrieve the previous value of the component (with getValue()), store the new local value using setValue(), and reset the submitted value to null. If the local value is different from the previous value of this component, fire a ValueChangeEvent to be broadcast to all interested listeners.

Autrement dit, la validation n'a pas lieu avec un null, même pas donc le required qui est testé dans validateValue. Dons les champs à string vide sont bien validé (cf etoile 2). Par contre les champs non soumis ne le sont pas.

Tout l'utilité de la chose est la gestion des composants qui ne sont pas nécessairement visible, mais qui ne passent pas par le mecanisme rendered=... (exemple le tabbedpane de tomahawk)

[lastrecrue]

Merci, je comprend mieux maintenant en gros mon problème ne peut pas être résolu en passant par validator ou converter.

[tchize_]

si il peux l'etre car votre champ est soumis à vide (string de longueur null, cf ci-dessus), pas supprimé de la soumission

De toute façon, je ne faisiat que rappeler le fait qu'on ne peux pas se fier aveuglément à la validation jsf pour els truc critiques, car elle est bidouillable par le client.

[lastrecrue]

en fait j'arrive a activé la validation n mais le value changelistener ne se déclenche que si la validation c'est bien passé a ce que j'ai compris ?

[romaintaz]

oui, la validation (ou plus exactement l'échec de celle-ci) est bloquante, donc pas de listener activée si la validation échoue.