Discussion :

[gailuris]

Bonjour,

Nous nous apprétons à internationaliser notre appli, la solution qui me parait évidente est celle qui est préconisée : RessourceBundle & co, puisque nous utilisons struts.

Cependant des personnes refractaire à l'utilisation massive de struts et de ces tags m'ont dit que les performances de l'appli risquaient de chuter (pour l'instant aucune chaine n'est externalisée)...

Alors voila : nous avons environ 1000 utilisateurs en moyenne pour 150 jsps environs.
Personelement, il me semble que, à part les temps de compilations des jsps (mais ce n'est qu'une fois par jsp...), les performances ne devraient pas (ou trés peu changer)

Quelqu'un aurait-il des retours d'expériences à ce sujet ?

Encore une fois je ne suis vraiment pas sur d'étre clair...

Merci d'avance,

Gailuris

[zekey]

Si vous utilisez Struts, je suppose que vous utilisez deja les tags bean:message donc je ne vois pas la différence avec l'i18n .

Franchement je vois pas bien ce qui pourrait ralentir.
N'oublions pas que les resources sont chargées au démarrage de l'appli et que par la suite il les cherche dans une hashmap.
Si différence de perf il y a c'est que sur une page jsp vous cumulez un sacré paquet de textes.

En plus comment internationaliser sinon comme cela ?
En faisant une jsp par langue ? Parce que sinon il faudra egalement gérer une hashmap.

[gailuris]

Si vous utilisez Struts, je suppose que vous utilisez deja les tags bean:message donc je ne vois pas la différence avec l'i18n .

Pour l'instant la majorité des chaines sont en durs dans les jsps (pas taper c'est pas de moi lol)

Franchement je vois pas bien ce qui pourrait ralentir.

La je suis tout à fait d'accord mais comme on me met des batons dans les roues je veux être sûr que l'impact sera négligeable...

En plus comment internationaliser sinon comme cela ?
En faisant une jsp par langue ?

C'est ce que les empécheurs de tourner en rond de ma boite veulent me faire faire... (sachant que notre site est déjà décliner 7 fois : une fois pour chaque client... )
Mais je ne le fairais pas !!

[zekey]

Nan la sinon tu me les envois, c'est en plus très simple à argumenter.
Un changement à faire doit être répercuté par langue. En plus les tests de toutes modifs doivent être faite en toutes les langues puisqu'il y a modification du code et donc possible risque de bug (c'est pas contre toi, mais moi aussi je suis un pro du copier coller foireux).

Nan vraiment faut pas.

[yolepro]

Sinon tu fais une migration en HTML... ca peut etre la solution pour que ca soit vraiment super rapide

Non, plus serieusement. Il faut voir plusieurs problématiques :

- Les performances, clairement entre du tout statique et du tout dynamique, les perf seront differentes. Maintenant sagissant des messages (via des Ressources), la différence ne sera pas flagrante si ce n'est par rapport à la monté en mémoire au démarrage de l'appli.

- La qualité de service. Aucune comparaison en terme de qualité de livrable entre du tout statique et du RessourceBundle. Il faut absolument que tu pousses dans ce sens, surtout que les modifications peuvent etre impactées directement sans arret relance. Tous tes messages son centralisés, la réactivité est fortement améliorée.

Deux arguments de poids je pense comparé a une barette de ram

[gailuris]

Merci pour vos réponses, elles confirme ce que je pensais (et ça me rassure... parce que sinon, je me disais qu'il y avait un paquet de grosses entreprises qui faisaient n'importe quoi ).

Sinon tu fais une migration en HTML... ca peut etre la solution pour que ca soit vraiment super rapide

Rigole pas, mon équivalent d'AMO ma sortis :

Il faut arreter avec les tags struts, on sais bien que ça ne marche pas !

Nan la sinon tu me les envois, c'est en plus très simple à argumenter.

Ok pas de problèmes lol.


Plus sérieusement, vous ne sauriez pas où je pourrais trouvé des bench qui démontrerais tout ça ?

[zekey]

Facile tu es fait toi même des benchs:
En plus les mauvaises langues pourrons pas dire que le bench est biaisé.

Tu utilises JMeter (un excellent outil de test de montée en charge) après tu fais une page avec plein de bean:message et la même chose avec une jsp (c'est important pas une page statique) mais avec des texts en durs.

Après ca tu compares les résultat sur 100 users en para.
Et tu dis:
Struts:
- Moins de modifs de code lors de changements de texte
- Pas besoin de refaire les tests de régréssions en toutes les langues
- Les textes peuvent être cherché (au démarrage) sur la DB. Plus besoin de toucher au sources.
- Pas besoin de décider dynamiquement de la prochaine page à charger en fonction de la langue moins de complexité donc moins de bug.

Et en plus sauf si tu as une quantité de texte monstrueuse ce ne sera jamais plus de quelques Mo en mémoire