En général, Livecycle Data Services est plutôt connu pour être le canal de communication Flex <–> Java de Adobe.
Moins connu - alors que très pratique -:voici comment générer en PDF vos données issues de Flex.
Comment ça marche ?
Le processus de génération utilisé par LCDS s’apparente aux technologies XSL/XSLT, en l’occurrence: fournir du contenu XML à une template, dans le but d’obtenir un document (ici PDF).
En pratique, le code client Flex fournit du contenu XML au service Java LCDS (1), lequel fusionne le modèle de document (template)(2) avec les données pour obtenir le document PDF final(3).
- la template (format pdf) assure la mise en page graphique et les scripts de rendering
- les données XML remplissent le formulaire
- le schéma XSD assure la liaison entre les données XML et les champs de la template Designer.
La valeur ajoutée LCDS
Quel intérêt d’utiliser LCDS pour générer du PDF par rapport aux API Flex/Java existantes (Itext, AlivePDF) ?
L’intérêt est multiple :
- L’éditeur WYSIWYG Livecycle Designer
L’environnement Livecycle Designer permet de personnaliser fortement le look final de votre PDF. Les documents générés sont largement supérieurs aux PDF générés avec des APIs tierces, en particulier grâce aux nombreux contrôles présents dans la toolbox (champs textes, tableaux, form fragments …) et un contrôle poussé sur la mise en page et la disposition des composants.
Même si, sachez le, une bonne maitrise du WYSIWYG sera nécessaire pour affûter son gabarit et régler les petits détails graphiques. La documentation Livecycle Designer (de bonne facture) sera votre allié indispensable pour maitriser un outil riche mais parfois peu intuitif.
Pour finir, rien ne vous empêche de créer votre gabarit à partir d’un PDF existant (fourni par votre client par ex) pour le rendre dynamique et de s’en servir comme modèle. Dans ce cas le gain de temps est encore plus conséquent.
Vous trouverez plus d’informations sur Livecycle Designer ici : http://www.adobe.com/fr/products/livecycle/designer/
- Intégration à Flex
Du point de vue du développement Flex/Java, la génération par LCDS représente un gain de productivité certain. D’abord car la charge de travail peut plus facilement être répartie entre plusieurs ressources (un designer pour la template, un codeur pour le code Flex/Java). Et d’autre part grâce au socle LCDS, qui nous laisse la possibilité de fournir le flux de données en XML E4X, soit directement à partir du client Flex !
Par conséquent, il n’est plus nécessaire de générer le contenu XML server-side …
C’est un gain de temps non négligeable … dans le cas, bien sûr, ou votre modèle AS3 est assez riche pour alimenter lui même la template.
Dernier point intéressant: la possibilité de mapper des images provenant du Flex à des contrôles images dans votre template (Exemple : générer un snapshot d’un contrôle charting Flex dans son PDF).
Tutorial
Prenons l’exemple d’une génération de fiche produit PDF pour un magasin en ligne.
La template Livecycle Designer ‘TemplateProduit.pdf’, embarque un schéma Xsd (produit.xsd) représentant les données du produit.
le schéma produit.xsd
<xs:element name="mainProduct" type="ProductVO"></xs:element> <xs:complexType name="ProductVO"> <xs:sequence> <xs:element name="name" type="xs:string" /> <xs:element name="isActive" type="xs:boolean" /> </xs:sequence> </xs:complexType>
La classe Flex ProduitVO.as contient toutes les informations du produit, et sa méthode toXml() convertit son contenu en E4X (en suivant la structure de produit.xsd). Soit :
var myProduct:ProductVO = new ProductVO(); // remplissage du produit ... myProduct.name = "produit1"; myProduct.isActive = true; service.generateProductPDF(myProduct.toXML());
La partie serveur est un jeu d’enfant. Le code de génération prend 10 lignes java :
public void generateProductPDF (org.w3c.dom.Document dataset) {
// todo call the xdp service
String templatePath = "C:TemplateProduit.pdf";
XFAHelper helper = new XFAHelper();
try { helper.open(templatePath);
helper.importDataset(dataset);
helper.save("C:output.pdf");
} catch (Exception e)
{
e.printStackTrace(); }\\ }




Hello,
Tous n’est malheureusement pas si simple. Si dans le principe c’est effectivement très simple, il reste des incohérences entre le monde flex et PDF. Un exemple simple est le richtexteditor qui permet de stocker les données de facon formater. Il aurait était judicieux que le format en sortie de ce richetexteditor soit compatible avec le richtext du pdf.
De meme a l’interieur du PDF, on peut programmer avec un language propriétaire ou javascript, mais pas d’actionscript, ca aurait ete trop simple.
Enfin, l’editeur wisiwig, si il a le mérite d’exister est a peine plus ergonomique que Itext…
Dommage que Adobe ne prenne pas plus à coeur l’intégration de ces différente solutions.