Dans cet article, je vais vous donner quelques astuces pour agrémenter la construction de votre export Excel.

Comment générer un fichier Excel via JAVA en verrouillant certaines cellules ?

Comment figer un volet avec POI ?

Comment créer un menu déroulant (liste de valeurs ou Drop Down List) ?

Un billet qui peut vous apporter quelques astuces et vous épargner quelques mauvaises surprises au moment de votre développement.

Controverse sur l'utilisation de POI : Il est dit dans la littérature trouvée sur Internet que POI consomme jusqu'à deux fois plus de mémoire que la librairie Jexcel. A vous donc d'utiliser la librairie la plus adaptée à votre projet, sachant que POI est à mon avis plus complet  et gère aussi les documents Word et XML. 

Pour ce premier billet, je souhaite aborder avec vous une question chère à tous nos clients actuellement : "Comment générer une édition (comme un courrier ou une facture) prête à être imprimée depuis une application métier ?"

Aujourd'hui il existe une multitude de solutions concurrentes et modernes pour répondre à cette problématique avec en règle générale une stratégie simple : "la solution retenue doit être cohérente avec la technologie de l'application métier ou du moins y être facilement intégrable". Sans être exhaustif, je citerai :

• Sql Server Reporting Service sur technologie .NET ;
• JasperReport côté Java ;
• BIRT toujours côté Java ;
• POI (et plus précisément HWPF pour la manipulation de documents Word) ;
• Serveur Open Office ;
• FPDF pour générer un PDF en PHP ;
• Plus une longue liste d'API disponibles et plus ou moins performantes.

La liste est donc longue ... trop longue même ... chaque produit étant supporté par sa communauté.

Si on creuse un peu plus le besoin de l'utilisateur final, la question se complique encore un peu car la solution doit aussi :

• S'appuyer sur un modèle comportant des zones dynamiques insérées entre des zones statiques ;
• Permettre à un non informaticien de modifier ce modèle ou au moins les zones statiques de ce modèle.

Et c'est précisément ce deuxième point qui, assez rapidement, démontre les limites des solutions actuelles.

Ce cas concret (il fallait que je le place pour ce premier billet) a été rencontré récemment par une équipe NETAPSYS sur un projet Java / J2EE : la solution d'édition devait être capable de générer un courrier à partir d'un modèle RTF comportant des zones statiques, des zones dynamiques mais aussi des conditions d'affichage du type "si la victime est hospitalisée alors affiche l'adresse de l'établissement de santé".

Après plusieurs prototypes et quelques déceptions, l'équipe a finalement retenu le couple technique "RtfTemplate / Velocity" pour répondre à cette question.

Dans mes prochains billets, j'aborderai avec vous les points suivants :

1. Description technique du prototype mis en place ;
2. Avantages et inconvénients mis en évidence par ce prototype ;
3. Retours d'expérience liés à la mise en œuvre de cette solution.