Tu confonds les développeurs et les utilisateurs des applications faites en DelphiCitation:
Envoyé par ApproxDev
C'est le métier de l'utilisateur qui décide du besoin technique
1) HTML
En 15 ans, j'ai utilisé du HTML qu'une seule fois pour afficher un Hint et j'ai utilisé le THTMLCredit de TMS
le HTML était lui même issu d'un XML transformé via un XSLT et affichait tout l'historique de modification des valeurs (un besoin de forte traçabilité pour l'utilisateur de qui modifiait quoi et quand)
C'était l'approche choisi en D5 parce que le développeur voulait s'amuser avec ces nouveautés de l'an 2000, je n'ai fait que l'améliorer et stabiliser
la même chose pouvait être faite en stockant les infos dans une table et en jouant avec des TLabel positionnés manuellement (ben oui, le TFlowGrid n'existait pas et TDBCtrlGrid aurait été visuellement trop lourd)
Mais c'était moins fun et moins innovant !
D'ailleurs ce développeur avait aussi fait un XLST qui transformait un XSL en DFM, et la DFM pouvait être chargé via ReadComponent
Clairement un délire technique pour exploiter à fond le XSLT
Sinon, la plupart du temps un TWebBrowser affichant le résultat d'un script PHP, cela ne va pas plus loin !
Delphi VCL\FMX c'est du client lourd, on a tout plein de composant pour afficher ce que l'on veut, pourquoi se faire chier avec du HTML
(perso, la partie IHM du web est une vraie tannée pour moi, je préfère coder la partie serveur qui retourne du XML ou mieux du JSON laissant les pro du JS et du CSS faire leur boulot)
2) RTF
j'ai utilisé le TRichEdit, le plus souvent en lecture seule (finalement comme pour le HTML)
J'ai travaillé 9 ans dans le Médical\Socio-Médical, c'est là ou j'avais le plus de "texte" à afficher ou à produire
Le RTF, était un grand classique des versions informatisées du Vidal, des catalogues d'appareil médicaux, d'un diagnostique CIM ou d'un acte CCAM.
cela se limitait souvent à un titre, un sous-titre et un texte
Le plus souvent l'utilisateur préférait une version épurée du texte dans la TDBGrid pour une lecture rapide et le TDBRichEdit soit en dessous soit accessible en double-clic pour un texte plus long
A l'époque faut dire que la résolution phare c'était le 800x600 voire le luxe avec un 1024x768, il fallait faire des compromis
Pour avoir inclu, l'éditeur de RTF fourni sur le CD de Delphi 5 dans des applications, tu vois rapidement, que mieux vaut utiliser Word en OLE et faire du Publipostage
Avec un modèle Word + Publipostage, tu as obtients un beau document au contenu enrichi tout beau et un code simple ne se préoccupant que des données
C'est faisable en OLE, même si un peu pénible
Avec TReportBuilder + TwwppRichEdit, c'est plus cher mais à l'avantage de fonctionner sans Word sur un serveur d'impression (quand tu imprimes 5000 à 20000 documents par jour, tu n'as pas peur d'investir en outil et matériel)
Depuis, les 6 dernières années, alors que les utilisateurs ont maintenant des machines puissantes et des résolutions HD (mais pas des écrans beaucoup plus grand, les pixels sont devenus plus petits)
Beaucoup d'utilisateurs demande qu'on passe leurs Windows en 125% ou 150% pour avoir du texte plus grand.
Au final, un écran 1920x1080 avec le scale Windows, revient à un écran 1024x768, on affiche à peine plus de chose pour privilégier le confort sans noyer l'utilisateur d'effet visuel inutile et encombrant !
Mes autres années de travail en robotique ou vidéo-surveillance, le seul HTML que j'ai vu c'était parce que les appareils intègrent souvent un server web pour leur administration et supervision
Pas besoin de le faire soit même, un ShellExecute ou un TWebBrower sur l'URL cible et basta !
Maintenant, je travaille sur un ERP maison,
quand tu as une base produit de 400000 références, avec autant d'image miniature et HD, avec le descriptif en 5 langues, tu vas à l'essentiel !
Ce n'est pas du texte enrichi qui aide à vendre les 10 000 000 de produits par an !
Dans quel cadre tu travailles pour être obsédé par le Texte Enrichi, pour moi, c'est un élément anecdotique de mon travail
A part, les ressources humaines qui utilise du publipostage pour générer les contrats de travail, c'est bien la seule chose dans ce genre
Tout le reste, c'est du PDF généré via ReportBuilder pour les bons de commandes, bons d'expédition, de réception, les factures, les avoirs, ce qui compte c'est l'exactitude, le respect de la législation, la clarté, la simplicité de lecture du document
Et puis, évidemment, le plus important c'est l'EDI qui l'accompagne pour que les systèmes soit interopérables pour que tous les acteurs gagnent du temps !
