Discussion :

[Lordsephiroth]

Bonjour à tous,

J'ai un petit soucis avec les formulaires au travers de JSF. Mon problème est réellement idiot et je suppose qu'il y a une façon simple de résoudre ça, mais je n'ai pas réussi à trouver de solution ni sur Google ni dans la FAQ du site.

Voici un exemple de champ de formulaire lié à un Bean qui détient les paramètres de la recherche que l'internaute demande (ici par exemple le numéro d'identification de la personne) :

Code :

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

<h:inputText value="#{PersonSearchBean.numeroPersonne}" />

Ce champ est de type numérique et n'est pas obligatoire (l'internaute recherche peut être par le nom ou le prénom). Mon soucis est que JSF initialise systématiquement la propriété numeroPersonne dans le bean PersonSearchBean avec la valeur zéro quand l'internaute ne remplis aucune valeur pour le champ.

J'ai bien entendu besoin de différencier le cas où l'internaute entre réellement le chiffre zéro dans le champ du cas où l'internaute n'a rien remplis (d'autant plus que je travaille actuellement avec une base de données où la première clé primaire avec auto incrémentation est 0 et non 1... ).

J'ai pourtant bien mis une variable de type Integer et non int, j'ai également tenté de mettre null comme valeur par défaut dans le PersonSearchBean pour le champ...

En résumé : comment différencier avec JSF l'envoi d'un champ vide et d'un champ avec zéro lorsque le type de la propriété du bean associé est de type Integer ?


Je parie que la solution est simplissime (impossible qu'un langage comme ça n'ait pas moyen de différencier les deux valeurs) et que je me taperai la tête en disant "mais bien sûr !!" dès que je verrai la solution.

Merci d'avance !

[romaintaz]

Il n'y a pas de raison, si tu as bien utiliser un Integer que JSF mette la valeur à 0 quand rien n'y est saisi...

Peux-tu nous montrer un peu plus de code ?

Sinon, as-tu essayé de tracer les appels au setter, par des logs, ou en mode debug, afin de savoir qui appelle cette méthode ?

[Lordsephiroth]

Le problème semble beaucoup plus complexe qu'il n'y paraît. D'après ce que j'ai pu trouver dans les spécifications finale de EL (Expression Language) située à l'adresse http://jsp.java.net/spec/jsp-2_1-fr-spec-el.pdf, la section 1.18.3 indique clairement que :

1.18.3 Coerce A to Number type N
■ If A is null or "", return 0.
■ If A is Character, convert A to new Short((short)a.charValue()), and apply the following rules.
... (beaucoup d'autres règles)

Il semble donc accepté, du point de vue des spécifications, qu'il n'y ait aucun moyen de différencier une saisie "vide" d'une saisie "0" par l'internaute dans le cas où le champ est lié par EL à un champ de type numérique (donc concerne je suppose également les Double, BigInteger, ... en plus des types int, double, float pour lesquels je suis entièrement d'accord que la conversion vers 0 s'impose).

En cherchant un peu plus, j'ai découvert que les serveurs web n'implémentent pas tous pareillement cette section des spécifications. Il semble donc que, par exemple, Glassfish ait refusé d'implémenter ce comportement "aberrant" de conversion. Ce problème peut survenir selon le conteneur web avec lequel on travaille.

Etant sur JBoss, je me suis intéressé à Tomcat et j'ai pu découvrir à cette adresse qu'un paramètre de configuration COERCE_TO_ZERO pouvait être utilisé pour adapter la configuration.

Encore plus en détail :

Tomcat n'implémentait pas correctement la spécification (donc montrait un comportement "logique" jusqu'en version 6.0.16. L'équipe de développement s'est rendue compte que la spécification n'était pas suivie et a fait un bugfix en version 6.0.17. La communauté n'ayant pas tellement aimé ce bugfix, Apache a introduit l'option COERCE_TO_ZERO quelques versions plus tard (je ne sais pas exactement laquelle).

Pour ceux qui tomberait dans un cas similaire, voici un lien qui donne une bonne solution avec un ServletContextListener pour changer le paramètre "à chaud" lors de l'initialisation du contexte :

http://stackoverflow.com/questions/5...ero-at-runtime

Après 5 minutes de test, j'ai l'impression que cette solution fonctionne parfaitement sur mon JBoss 5.1.0 GA.

Je n'ai aucun recul quand aux implications de l'activation de cette option.

J'espère que cette réponse sera utile à quelqu'un passant par ici. Je pense d'ailleurs que ça pourrait être un point intéressant pour la FAQ JSF (erreurs courantes ou trucs et astuces), il faudra que j'y songe si j'ai un moment un de ces jours .

Amicalement,

Patrick

[romaintaz]

Excellente analyse !

Cela semble plausible. Je m'étonnais n'avoir jamais rencontré un tel comportement, mais étant resté à Tomcat 5.5, ceci peut expliquer cela...

Bon à savoir en tout cas !

[bradev]

Salut
Merci Mr Lordsephiroth pr cette analyse. moi même J'ai trouvé ce problème lors de déploiemet ds tomcat -6-0-32 même si ça marche en localhost (tomcat -6-0-14)