FB + Delphi + Publication de doc [Résolu]

[lefju cabro]

Bonjour,

Je développe un projet sous Delphi XE2 et FB 2.5.

Je cherche une solution pour publier un rapport à partir:

• des données contenues dans la bdd
• des images contenues dans la bdd
• d'un fichier squelette contenu dans la bdd.

Ce fichier sera éditable à partir de l'application et sera composé de balises à remplacer par les données de la bdd lors de la publication du document (ex: "balise_nomentreprise" du fichier squelette sera remplacée par "groggle" lors de la publication).

Quelle serait la meilleure solution pour mettre en place un tel outil ?
Je me demande:

• quel type de fichier je dois utiliser (word, html, xml ?)
• comment le stocker dans la bdd(blob je suppose) ?
• comment avoir une visu modifiable de ce fichier squelette (composant vcl?) ?

L'insertion du fichier squelette dans la bdd n'est pas obligatoire.

Par contre, pour l'avoir déjà utilisé dans une autre vie, je pense que je n'utiliserai pas OLE/Word car trop dépendant des versions de Word installées sur les postes.

Merci pour vos retours.

[ShaiLeTroll]

l'XML me semble le plus ouvert
Surtout couplé à un XSL qui te permettra dans le transformer en un autre XML, en HTML, en JSON ou même en format DFM

les outils de Reporting comme Report Builder, utilise une DFM comme format de stockage du modèle, après tout, c'est qu'un ensemble de TComponent que l'on peut imbriquer dans des TCollection
ou même des TGraphicControl qui gère le Canvas aussi bien à l'écran qu'à l'impression


Pour le stockage, j'ai stocké en BLOB, des Word, Excel, PDF ..., perso, j'utilise souvent une table dédiée à cela, après c'est juste des jointures pour associer un ID Lamda à un ID de Document
J'hévite les blobs directement avec une autre table de donné, surtout si l'on a tendance à utiliser trop souvent le SELECT *

En C++Builder, j'ai récemment utilisé un TClientDataSet pour gérer une contenu "polymorphe" d'une table !
Cette table est composé d'une clé primaire (deux clé étrangère) et d'un BLOB contenant le binaire Midas, le contenu de celui-ci peut varier car exploiter par différentes implémentations de la même interface dans plusieurs DLL et je n'avais pas envie de faire une table par implémentation

Pour le merge de balise, faudrait te trouver un équivalent Delphi au Smarty du PHP

Perso, j'en ai fait un récemment en C++Builder, un RTF contenant des <BALISE>, ouverture du fichier avec un TStringStream, des StringReplace brutal et pas optimisé, et ça génère un RTF mergé prêt à être imprimé au besoin !

Pour intégrer un Builder, tu as des composant comme TJvInspector, alors l'outil de Scripting de TMS

le XML génére une DFM, tu joues avec l'IDE de TMS, puis une fonction Delphi te retransforme la DFM en XML



J'avais fait la même chose en Delphi, il y a quelques années

[lefju cabro]

Bonjour ShaiLeTroll,

Je te remercie pour ta réponse même si de nombreuses notions (DFM ? C'est le même DFM que les fiches Delphi ?) dont tu me parles sont obscures pour moi

Pour le stockage, j'ai stocké en BLOB, des Word, Excel, PDF ..., perso, j'utilise souvent une table dédiée à cela, après c'est juste des jointures pour associer un ID Lamda à un ID de Document
J'hévite les blobs directement avec une autre table de donné, surtout si l'on a tendance à utiliser trop souvent le SELECT *

OK, j'étais parti sur ce modèle de base.

Pour intégrer un Builder, tu as des composant comme TJvInspector, alors l'outil de Scripting de TMS
le XML génére une DFM, tu joues avec l'IDE de TMS, puis une fonction Delphi te retransforme la DFM en XML

Tu me parles de la manière dont l’utilisateur pourrait construire son fichier à travers mon appli ? TJvInspector ne fait pas ça il me semble .
Il faut pour l'utilisateur un éditeur de texte complet (type quasi-Word) intégré au programme dans lequel il pourra mettre en page son doc et ajouter ses <balises>. Ensuite j'enregistre le fichier au format xml.

Perso, j'en ai fait un récemment en C++Builder, un RTF contenant des <BALISE>, ouverture du fichier avec un TStringStream, des StringReplace brutal et pas optimisé, et ça génère un RTF mergé prêt à être imprimé au besoin !

Je pensais faire de même sur le fichier xml mis en page par l'utilisateur. Tu dis que c'est brutal et non optimisé. Comment faire mieux ?

Merci

[ShaiLeTroll]

Envoyé par lefju cabro

DFM ? C'est le même DFM que les fiches Delphi

le même DFM, manipulable via TStream.ReadComponent\Write et les fonctions ObjectTextToBinary\ObjectBinaryToText pour convertir une DFM binaire en DFM Texte et réciproquement

Envoyé par lefju cabro

Tu me parles de la manière dont l’utilisateur pourrait construire son fichier à travers mon appli ? TJvInspector ne fait pas ça il me semble .

Oui, ce n'est qu'une partie, j'utilisais Greatis Form Designer pour cela !
C'était pour construire des écrans !

Un Rapport c'est pas très différent, c'est un tas de Label

Mais, tu peux faire plus simple avec RTF et Wordpad, l'avantage est que RTF est simple à modifier à la main par rapport à un fichier word, et que son format est moins "fluctuant"

Envoyé par lefju cabro

Je pensais faire de même sur le fichier xml mis en page par l'utilisateur. Tu dis que c'est brutal et non optimisé. Comment faire mieux ?

Le RTF modèle dans la dernier appli fait 2Ko, c'est quasi-instantanée !
Disons que pour un fichier de 1Mo, ça passera, tout dépend le nombre de balise, dans ma problématique, c'était des noms de champ d'une table (environ 60)

Tu verras par la suite pour les perfs, fait juste un code assez souple pour faciliter par d'un "merger" à un autre au besoin


As-tu étudier FastReport et un export en PDF ?
Cela peut faire cela aussi !

[lefju cabro]

Merci pour tes conseils ShaiLeTroll mais je suis perdu.

J'ai regardé les DFM et Greatis Form Designer mais je ne pense pas (ou alors je ne vois pas) comment l'utiliser dans mon cas. Et c'est peut-être trop puissant pour ce que je souhaite faire.

Concernant FastReport, que je connaissais uniquement de nom, j'ai pu tester une version d'essai mais le paramétrage du document par un utilisateur me parait compliqué: la création de champs et le lien avec la donnée rebutera nos utilisateurs. Ou alors existe-t-il une méthode que je pourrai utiliser dans Delphi de manière conviviale ?

Je souhaite un éditeur de texte facile à utiliser/modifier/paramétrer et très amélioré (presque comme Word mais sans le problème de version).
Serait-il possible de:
- créer un fichier Word qui sera modifié par l'utilisateur
- enregistrer ce ficher Word dans la BDD au format XML
- modifier le XML contenu dans la BDD dans Word
- remplacer les balises du XML lors de la publication
- publier ce XML avec la mise en page du Word
Possible ou je suis en plein délire ?

Merci

[ShaiLeTroll]

Quel est le format souhaite à la sortie ?
Une impression papier ?
Une page Web en ligne ?
Un Fichier PDF ?

Le plus difficile sera la modification façon Word !

Pourquoi tu ne commences pas par un RTF et Wordpad, un truc simple
un TRichEdit pour la modification et tu pourras fournir l'ajout des tes balises !

De te façon, pour certains utilisateurs même une <BALISE> c'est déjà trop compliqué !


Si c'est un projet pro, refléchi à de la prestation, fait toi un outil facile à utiliser pour un développeur ou un utilisateur "averti", tu pourras soit vendre de la formation, et pour les flemards, tu vends de la prestation pour configurer leurs impressions et autres courriers


Pour le moment, tu es en train de vouloir refaire Word et ses champs de fusion !

ReportBuilder équipé d'un TwwRichEdit gère des RTF avec balise, il fait automatiquement les merges

Je l'avais fait à la main car je devais générer un fichier TXT non formaté au lieu d'une sortie PDF\Papier, je n'avais pas trouvé sur le ReportBuilder comment faire une telle sortie, d'où un merge à la mano !
En fouillant, quelques temps plus tard, je pense que RB aurait pu me le faire !
Le code fonctionnait, TPCM, comme c'était pour de l'envoie en masse, je maitrisais mieux l'affaire !


Tu pourras imaginer un système XML <-> HTML par la suite mais cela me semble peut-être inutilement complexe pour ta problèmatique

[lefju cabro]

Quel est le format souhaite à la sortie ?
Une impression papier ?
Une page Web en ligne ?
Un Fichier PDF ?

Le fichier de sortie doit être électronique et modifiable par l'utilisateur. Ce logiciel professionnel sera utilisé dans un milieu technique. La publication du fichier de sortie contiendra les valeurs d'indicateurs techniques à partir desquelles l'utilisateur fera son diagnostic. Et c'est ce diagnostic que l'utilisateur va saisir dans le document de sortie avant de l'imprimer (papier/pdf).

Pourquoi tu ne commences pas par un RTF et Wordpad, un truc simple
un TRichEdit pour la modification et tu pourras fournir l'ajout des tes balises !

Je vais soumettre l'idée mais je pense que ça ne sera pas accepté car le RTF est trop limité.

De te façon, pour certains utilisateurs même une <BALISE> c'est déjà trop compliqué !

Tu as raison, c'est pour cela que je dois faire au plus simple: Word me paraissait bien car connu de tous.

Si c'est un projet pro, refléchi à de la prestation, fait toi un outil facile à utiliser pour un développeur ou un utilisateur "averti", tu pourras soit vendre de la formation, et pour les flemards, tu vends de la prestation pour configurer leurs impressions et autres courriers

Le logiciel s'adressera à des techniciens dont la connaissance de l'info est parfois limitée.
Dans ce cas, ok pour prévoir de la formation et/ou prestation pour config de rapport.
Pour les autres, tu me conseillerais plutôt d'utiliser RaveReport (fourni avec EX-2), FastReport ou ReportBuilder intégré dans mon logiciel construit sous XE-2 et FB ?

Merci

[ShaiLeTroll]

Si c'est ce fichier doit être en format électronique, il faudrait étudier si il existe déjà des standards lié aux métiers que tu cibles ou même plus générale

Par exemple en Santé, il y a HPrim par exemple.

Le fichier de sortie doit être électronique et modifiable par l'utilisateur

le "modifiable" me choque, est-ce que le fichier généré est modifiable ou alors c'est via ton logiciel que l'on change les données dans FireBird et tu regénère une nouvelle version du document (anulant le précédent)

Pour une question de traçabilité, j'aurais tendance à dire que tout doit être dans FireBird, ce "fichier" n'est qu'une finalité mais pas un moyen !
Mais cela dépend énormément de ton métier !
Tu es vague, une clause de confidentialité ?
Mais du coup difficile de bien comprendre ta problématique métier et donc te proposer les bonnes technologies

Si ce fichier n'est modifié qu'au sein d'une entreprise sur un LAN, ton application Delphi sera tout à fait approprié pour gérer le "fichier" via des TForm, TEdit ... la version finale n'étant généré qu'en dernier recours

Tu peux considérer plusieurs niveaux d'utilisateurs, ce qui vont "créer" les formulaires et ceux qui vont "répondre" aux formulaires
A chaque formulaire est associé un rapport (voir si l'on peut en code pré-créer un rapport pour que l'utilisateur n'ait qu'à modifier son aspect sans se préoccuper des données)

Si ce fichier peut-être modifié par des intervenants volatiles (un peu partout en france ou ailleurs), peut-être qu'une application Web serait préférable pour que tout utilisateur autorisé puisse consulter et modifier son document
une version téléchargeable en PDF pour la finalité

Tu as des logiciels de gestion de contenu (CMS), tu as aussi des outils de formulaire en ligne comme Drupal, Voozanoo ou Google Forms

[lefju cabro]

Si c'est ce fichier doit être en format électronique, il faudrait étudier si il existe déjà des standards lié aux métiers que tu cibles ou même plus générale
Par exemple en Santé, il y a HPrim par exemple.

A notre connaissance, il n'existe pas de solution/standard.

Mais cela dépend énormément de ton métier !
Tu es vague, une clause de confidentialité ?
Mais du coup difficile de bien comprendre ta problématique métier et donc te proposer les bonnes technologies

Mon logiciel va être utilisé pour de la prestation technique: des mesures sont effectuées sur site (connexion internet rarement dispo) et enregistrées dans la BDD. Ces mesures sont traitées pour fournir des indicateurs qui aideront l'utilisateur à faire son diagnostic (RAS ou en panne). Le diag. est également stocké dans la BDD.

le "modifiable" me choque, est-ce que le fichier généré est modifiable ou alors c'est via ton logiciel que l'on change les données dans FireBird et tu regénère une nouvelle version du document (anulant le précédent)

Avec ce que je viens de décrire, je me rends compte que je n'ai pas forcément besoin d'avoir un fichier modifiable. C'est juste que c'est plus confortable pour un utilisateur d'avoir un fichier éditable afin d'y rajouter d'autres infos qui ne pourraient pas être dispo dans la BDD.

En conclusion, je pencherai vers un outil de reporting. Ai-je raison ? Si oui, tu me conseillerais RaveReport (fourni avec EX-2), FastReport ou ReportBuilder intégré dans mon logiciel construit sous XE-2 et FB ?

Merci

[SergioMaster]

Rave aurait été parfait , il y a même une possibilité payante pour avoir une modification pour l'utilisateur. Le problème Rave n'est plus vraiment pérenne
(plus fourni avec XE3)

[ShaiLeTroll]

Envoyé par lefju cabro

Mon logiciel va être utilisé pour de la prestation technique: des mesures sont effectuées sur site (connexion internet rarement dispo) et enregistrées dans la BDD. Ces mesures sont traitées pour fournir des indicateurs qui aideront l'utilisateur à faire son diagnostic (RAS ou en panne). Le diag. est également stocké dans la BDD.

Donc utilisation de la BDD assez large

Donc soit une appli Web ou même une application mobile FMX utilisant un serveur DataSnap Rest ou JSON pour échanger les données
Mais cela nécesiste une connexion internet, avec un SmartPhone, ce n'est plus aujourd'hui vraiment un problème

Soit un mode briefcase avec des XML de TClientDataSet, ton programme stockée sur une clé USB, il met à jour des XML sur la clé USB

Lorsqu'une connexion réseau est disponible (ou que l'intervenant rentre au bercail), le XML est fusionné dans la DB Principale, cela peut nécessiter de la Consolidation des données lors de l'import

Cela peut aussi se faire avec un FB Embedded

D'ailleurs, si cela se trouve, tu n'as jamais prévu de faire une DB centralisé, mes réponses, étaient plutôt orienté centralisé ou mutualisé avec des possibilités de terminaux non connecté, maintenant le terme à la mode c'est le Cloud mais c'est déjà concept que l'on utilise déjà massivement dans beaucoup de domaine où l'information est le coeur du métier

Tu as beaucoup d'appli qui utilisait ce genre de système de synchro avec des Palm ou PSION par exemple !
Typiquement les livreurs, il scanne le code barre, une signature, hop à la fin de la journée, le terminal sur le dock, upload des données ...
J'ai vu la même chose dans des entrepots lors des inventaires (le flux de données dans cette circonstance dépassant les capacité en HF pour les manip quotidienne de Picking, il était plus efficace d'utiliser un mode filaire)

Le terminal pouvant évidemement être aussi un ordinateur portable !
C'est même le plus fréquent !

Envoyé par lefju cabro

C'est juste que c'est plus confortable pour un utilisateur d'avoir un fichier éditable afin d'y rajouter d'autres infos qui ne pourraient pas être dispo dans la BDD.

C'est le problème, tu aurais ainsi DEUX lieux de stockage, la BDD et ces fichiers qui se baladent !
Pour faire des statistiques, ce n'est pas évident !

Envoyé par lefju cabro

En conclusion, je pencherai vers un outil de reporting. Ai-je raison ?

La durée de vie des outils de reporting dans Delphi a toujours été d'environ 5 à 7 ans, QuickReport 10 plus tard existent toujours en version séparée, il serait surement de même pour RaveReport, c'est une histoire de business !

Tout ceux qui ont des centaines de rapport en Rave acheteront la licence, ça coutera moins cher que de tout migré dans un nouvel outil

ReportBuilder étant déjà externe, c'est un choix, tu peux d'ailleurs intégrer le Builder de Rapport à ton appli !
La plupart du temps, je ne m'occupais pas des rapports, c'était les "installeurs" qui créait des Modèles en utilisant un outil de requêtage (assez poussé d'ailleurs, permettant de sortir des stats, des données croisées ...)
Les "installeurs" utilisaient l'appli Delphi pour créer les rapports dans un contexte DB très ciblé


Tu devrais analyser les besoins de tes utilisateurs, savoir au quotidien ce qui serait VRAIMENT pratique et qui garantirait la QUALITE des données !

Peut-être que ce rapport ne sera qu'une version "finale" des données récoltées

ou alors une version intermédiaire
un utilisateur créer un modèle de fiche, les intervenants utilisent une version papier de ces fiches, il gribouille leurs commentaires, des opérateurs de saisie recopies les données papier dans le logiciel, puis au besoin une version finale est imprimé !
C'est très courant cela !

Il existe d'ailleurs, des Stylo numériques sur papier pré-imprimé pour justement éviter la phase de saisie, voir les solutions d'Anoto par Exemple

[lefju cabro]

Je vous remercie pour vos réponses, je pense utiliser un outil de report (qui reste encore à définir)