[Tsp-devel] Au sujet du mapping Objet/XML dans la partie Java...

[Stephane GALLES]

Bonjour,

Simplement pour clore un petit débat qui s'était instauré
au sujet de la possibilité ou pas d'utiliser une lib externe
de mapping Objet/XML (ce que j'avais suggéré) pour JTSP

Après avoir aprofondi la question il semble bien que
le cout de la dépendance sur une librairie externe (genre Digester)
soit trop important pas rapport au peu de XML que nous avons à
mapper

Néanmoins je n'aime toujours pas DOM pour faire cela pour deux
raison :
- Peu performant : l'arbre XML est chargé entiérement en mémoire
avant même d'avoir été parsé (cela fait donc au moins deux parcours).
Cela bouffe du temps et de la mémoire pour rien. Cela m'inquiète
quand je vois qu'on parle de providers avec 2^42 symboles.
C'est du outOfMemory assuré.
- Pénible : cela donne du code super procédural. Poua !

Donc, j'ai commencé à regarder SAX qui est connu pour être plus
performant, mais plus dur à utiliser.
Néanmoins, j'ai trouvé des patterns dans un article sur le Web, pour utiliser
SAX dans le but de mapper du XML sur des objets, et le résultat semble super
élégant et maintenable, bien plus que du DOM (et en plus performant).

Donc, si tu est OK avec cela Eric, on oublie mon histoire de lib
externe, et je tente une approche avec SAX de cette manière. Si
cela ne fonctionne pas, on repassera à DOM. Si cela fonctionne,
je mettrai le code factorisable dans tsp.util (parceque on va
devoir faire du mapping à plusieurs places)

Si quelqu'un est intéressé par l'article, le voici :
http://www.javaworld.com/javaworld/jw-10-2000/jw-1006-sax.html

Au fait, Eric, c'est un détail, mais tu serait OK pour un nom
de package tsp.core.consumer.simple ou tsp.core.consumer.easy pour
l'API TSP niveau n, ou bien tu préfères quand même le nom que tu voulais donner
initialement ? Si oui, je m'inclide (cette question c'était perdu
dans le flot d'email de la semaine passée)

Steph.