Discussion :

[lyxthe]

Bonjour,

je souhaite exectuer un déserialization pour laquelle certaines balises sont optionnelles. Lorsque c'est le cas, les champs que doivent alimenter ces balises restent à null (jusque là tout fonctionne bien)

Après la deserialization, je parcours l'ensemble de mes objets dans une méthode de check concistency, et pour tous les attibuts à null, je considère que la balise optionnelle n'était pas présente dans le xml et j'effectue un traitement particulier en conséquence (soit je laisse à null soit j'affecte un objet générique ...).

Mon problème est que certaines de ces balises optionnelles n'alimentent pas des objets mais des types primitifs (int, double, boolean ...) et dans ce cas je ne peux pas tester après coup s'ils sont à null (de ce que j'ai compris un type primitif ne peut pas être à null).

J'ai fait des converter qui, quand la valeur n'est pas présente, affecte une valeur que je sais reconnaitre (par exemple Integer.MINVALUE) mais ça ça marche si la balise est bien présente mais la valeur absente. Lorsque la valeur ET la balise est absente, je ne sais pas comment vérifier si mon attribut a été alimenté ou non.

Est-ce que vous savez comment je peux tester si un attribut de type primitif a

[rg77140]

Bonjour,

Pour moi ton problème n'est pas lié à Xstream. Tu dis que dans ton XML tu peux avoir des valeurs optionnelles mais tu modélises un objet Java qui ne peut pas représenter une valeur optionnelle (tu as raison une variable primitive ne peut pas être nulle). Derrière tu vas te battre avec ton framework alors qu'il n'y a pas lieu...

Si tu as un entier qui est optionnel le bon type Java pour le représenter est Integer, si c'est un booléen optionnel le bon type est Boolean, ... Pas de converter, pas de "magic value", pas de bidouille, pas besoin de se battre avec le framework pour combler une modélisation erronée.

Romain.

[tsuji]

Mon problème est que certaines de ces balises optionnelles n'alimentent pas des objets mais des types primitifs (int, double, boolean ...) et dans ce cas je ne peux pas tester après coup s'ils sont à null (de ce que j'ai compris un type primitif ne peut pas être à null).

Je pense c'est bien raisonné, mais, ce n'est pas d'histoire complète en tenant compte le plate-forme qu'on y raisonne. En XStream, il ne le distingue pas trop type primitif et sa version dite "boxed". Il utilise systématiquement refléxions...

J'ai regardé mon cas avec les données du texte qui n'est pas vraiment primitif. Quand je le modifie pour un cas primitif authentique, effectivement, ça pose de problème de tester avec null. Donc, je suis d'accord avec op et aussi avec rg77140 en ce qui concerne le parcours le plus simple c'est d'utiliser la version "boxed".

Une piste de contourner le problème en tant que tel est effectivement suggerée dans le faq :
http://xstream.codehaus.org/faq.html...flection_types

ps J'ai fait une édition corrigée d'erreurs dans le message original et puis je fais une consolidation ici et maintenant pour ne pas créer confusion pous les lecteurs par hazards futurs comme il n'y encore aucune réaction depuis l'édition corrigée après un délai raisonnable. Je suis désolé pour le confusion qui puisse involontairement crée.