Discussion :

[Invité]

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

[azerr]

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

[Invité]

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

[Invité]

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 :

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

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 :

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

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.

[Invité]

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

[hwoarang]

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...

[tchize_]

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

J'en compte 4

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

[hwoarang]

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