Edition multi format

Bonjour.

Je suis confronté à une problématique, et j'aurai aimé connaitre votre avis afin de partir dans la bonne direction.

En Java, je vais avoir une liste d'activités exercées par des personne durant un mois données. Sur ces activité, je peux être amené à faire des calculs (ce que je sais faire).

Suite à cela, je souhaiterai gérer plusieurs éditions :
- une édition texte un correspond à un fichier d'interface
- un fichier PDF qui globalement, correspond à ce fichier texte, mais en clair et mis en forme pour un utilisateur.

Je connais (un peu) la bibliotèque itext pour la PDF.
Dans mon cas, je me demande s'il ne faudrait pas passer par un format intermédiaire (exemple XML). A partir de celui-ci je le reformaterais, soit en texte, soit en PDF, ou s'il faut à partir des mes objets java, gérer séparément ces deux éditions.

Merci d'avance

Bonjour johannsan,

Pour l'edition texte, moi je ferais au plus simple, autrement dit, je parcourrais mes activités et je genererais un flux texte.

Pour l'edition PDF, soit je ferais ca direcetement en iText en suivant la même logique (parcours des activites pour construire un document PDF via les structures table, paragraph, chunk etc d'iText) soit j'utiliserais XDocReport qui te permet de construire ton rapport avec MS Word (docx) ou LibreOffice (odt) en utilisant des champs de fusion et de merger ton rapport avec des données Java et de le convertir en PDF ou HTML.

Tu pourras ainsi proposer plusieurs modeles pour générer tes editions et ca sera très facile de modifier ton edition, car tu le feras avec MS Word ou OpenOffice.


Angelo

Merci pour votre réponse.

Je pense que je vais partir sur itext comme je l'imaginais. En effet, mon état ne doit pas être modifiable par l'utilisateur, et il risque d'être assez complexe : tableau, totaux... Je pense que c'est plus simple avec itext, surtout que j'ai "quelques" bases (j'ai déjà fait quelques éditions).

Donc globalement, ça va me faire deux grosses boucles. ce qui est surement plus propre qu'une grosse qui fait tout à la fois...

Merci

Bonjour.

J'aurais tout de même une question pour avoir votre avis.

J'ai donc une classe qui décrit les champs composant une ligne d'enregistrement
exemple :
- l’année doit être sur 4 caractère
- le mois doit être sur deux
- une chaîne doit être sur 40 caractères
- un nombre droit être par exemple sur 7 caractères (ex : 0010080) pour 100.80

Pour vous, est-il préférable que ma classe ait 3 attributs comme cela

Code:

---

1 2 3 4

String annee String moisSur2 String maChaineSur40 String monNombreSur7

---

dans lequel je m'occupe du formatage dans les setter

ou que ma classe ait 3 attributs comme cela

Code:

---

1 2 3 4

int annee int mois String maChaine float monNombre

---

dans lequel je m'occupe du formatage en sortie, c'est à dire soit dans les getter (getAnnee, getMois, getMonNombre) ou encore dans d'autres methodes qui permettent d'avoir la valeur formatée, c'est à dire (getAnneeFormattee, getMaChaineFormattee...)

Merci d'avance pour vos avis qui me seront bien utiles.

Personne n'a de réponse à m'apporter?

Moi, je partirais plutot sur les types les plus précis. Pourquoi ? Parce que partir sur 4 strings te permettra de creer ta liste plus vite (puisque l'objectif est de ne pas avoir à verifier la validité des données) mais ne te dispensera pas de devoir t'assurer que les formats sont bons à un moment ou à un autre. Donc, ce que tu auras gagné au départ, tu le perdras plus tard. Ensuite, le fait de stocker des string fait qu'à chaque utilisation, il faudra parser pour effectuer des operations...

Citation:

---

Envoyé par johannsan

Pour vous, est-il préférable que ma classe ait 3 attributs comme cela

---

J'en compte 4 :aie:

Ma réponse est "tout dépend". Ainsi, si je suis d'accord concernant l'année et le mois en int, pour le float, je suis réticent. Tu nous décrit ce qui est une virgule fixe avec une précision de 2 et tu voudrais stocker ça dans une virgule flottante... Tu va perdre en précision dans les deux sens de conversion. Maintenant, à ton niveau, une perte de précision dans un sens sera compensée par la deuxième perte dans l'autre sens. Mais quand même, stocker soit un int nomNombreEnCentiemes; soit un BigDecimal nomNombreAVirguleFixe; serait plus propre.

Pour ce qui est de la validation, j'ai tendance à la laisser à l'extérieur des getters / setters. Le format valide ne concerne que tes input/output. Rien ne dit que tu ne voudra pas, dans le futur, stocker dans ce même objet, des données temporaires qui ne seront pas limitées elles :)

Bien vu pour la perte de précision du float. A garder en tete. Ceci dit, si j'en crois le message #1, le but est de faire des calculs. Donc je continue à penser que le mieux est de passer par les types précis...

Mais en ce qui concerne la validation, je suis d'avis de la faire le plus tot possible afin de pouvoir notifier l'utilisateur que son fichier est invalide. Je prefere me faire jeter des le debut si mon fichier n'est pas bon plutot que de me prendre une exception apres 4 formulaires que je me suis pris la peine de remplir parce que j'ai fait une faute de frappe dans mon fichier :)

Bonjour.

Je ne comprend pas pourquoi vous me parlez de "validation", et de perte de précision.

Pour rappel, mon fichier est une sortie, et non une entrée donc je n'ai rien à valider vu que c'est moi qui crée le fichier.

Pour reprendre tout depuis le début.

J'ai ma table activité dans laquelle j'ai des enregistrements de type varchar et number.
Sur chaque ligne de ma table, je peux être amené à faire des calculs "horizontaux", et enregistre les résultats dans cette même table, et donc sur chaque ligne.

Je récupère donc tous mes enregistrements dans une liste d'Activite :

Code:

---

1 2 3 4 5

int annee int mois String maChaine float monNombre float monResultatDeCalcul

---

exemple de calcul : monResultatDeCalcul = monNombre * unTaux
Si je comprends bien, vous me dites d'éviter les float pour utiliser un BigDécimal.
Pour votre info, j'utilisais les float car sur un ResultSet, j'utilisais rs.getFloat() sur un champ avec décimale.



Ensuite, comme j'indiquais le "17/01/2013", j'ai une classe qui décrit les champs composant une ligne d'enregistrement dans mon fichier texte.
Dans celle-ci il n'y a pas de calcul, elle ne me sert qu'à "remplir mon fichier".

En gros, je vais faire une boucle sur ma liste d'Activité, et pour chaque Activite je vais remplir une classe "ligneDEnregistrement".

D'où ma question posée le 17/01/2013 sur le format de cette classe "ligneDEnregistrement"

Merci

En principe, s'il y a eu calcul à un moment ou à un autre, s'éloignant donc du format pur String, alors on gardera un type spécialisé jusqu'au dernier moment et on formatera en String au moment d'écrire.
Si on ne fait aucun calcul et qu'on retranscrit juste ce qu'on a lu, d'une source texte vers une destination texte, alors là ça se discute. Question de goût, et, justement, de validation et de conservation de la précision.

Et oui, si tu passes par un type numérique, tu devrais éviter les float. Si c'est un calcul exact à virgule fixe, il faudrait utiliser BigDecimal. Si ce n'est pas exact et pas spécialement à virgule fixe, un double sera plus adapté.
On n'utilise jamais de float, à part pour les calculs de rendu de coordonnées 2D ou 3D.

Citation:

---

Envoyé par johannsan

Je récupère donc tous mes enregistrements dans une liste d'Activite :

Code:

---

1 2 3 4 5

int annee int mois String maChaine float monNombre float monResultatDeCalcul

---

---

Ben te casse pas la tête alors, garde le format qui colle le mieux au buisness logic et fait ton formatage en sortie.

Citation:

---

Envoyé par johannsan

Je ne comprend pas pourquoi vous me parlez de "validation", et de perte de précision.

Pour rappel, mon fichier est une sortie, et non une entrée donc je n'ai rien à valider vu que c'est moi qui crée le fichier.

---

Toi, tu sais que ce fichier n'est utilisé qu'en sortie. Nous, on ne peut pas deviner. Comme tu parlais de stocker dans tu classe directement sous forme de String, on a supposé (logiquement) que c'est parce que tes données d'entrée sont sous forme de String.

Citation:

---

Envoyé par johannsan

Si je comprends bien, vous me dites d'éviter les float pour utiliser un BigDécimal.
Pour votre info, j'utilisais les float car sur un ResultSet, j'utilisais rs.getFloat() sur un champ avec décimale.

---

Sur un ResultSet, il y a aussi getDouble() et getBigDecimal(). Ce qu'il faut comprendre, c'est que float est moins précis que double qui est moins précis que BigDecimal (et bien sur, plus ils sont précis, plus ils prennent de place en mémoire et plus les opérations sont longues à effectuer). Bref, à toi de voir lequel est le plus adapté en fonction de ce que tu veux.

Citation:

---

Envoyé par johannsan

Ensuite, comme j'indiquais le "17/01/2013", j'ai une classe qui décrit les champs composant une ligne d'enregistrement dans mon fichier texte.
Dans celle-ci il n'y a pas de calcul, elle ne me sert qu'à "remplir mon fichier".

En gros, je vais faire une boucle sur ma liste d'Activité, et pour chaque Activite je vais remplir une classe "ligneDEnregistrement".

D'où ma question posée le 17/01/2013 sur le format de cette classe "ligneDEnregistrement"

---

On ne pouvait pas savoir que cette classe ne servait qu'à remplir le fichier d'enregistrement. D'ailleurs, si c'est le cas, on peut meme se demander si elle a un vrai intérêt m'enfin c'est un autre débat. Pour en revenir à la question, si elle ne sert qu'à remplir un fichier texte, c'est une question de gout. Par principe, je n'aime pas formater dans un getter/setter. J'aurais donc tendance à utiliser les types spécialisés et ne transformer en string que pour aller dans le fichier. M'enfin c'est une question de point de vue et je pourrais aussi défendre le point de vue contraire...

Merci pour vos réponses.

Concernant le choix de float/double/BigDecimal, il est vrai que je n'ai jamais utilisé BigDecimal, et il est étonant que je n'ai jamais rencontré de problème sur les résultats obtenus (exemple résultat d'une multiplication)
Peut être car j'utilise des arrondis à la deuxième décimale.

Mais en effet, la lecture du cours Java jmdoudou est très intéressant sur les bigDecimal et permet de comprendre : http://java.developpez.com/cours/

en général, pour des calculs, des floats / double suffisent ;)