Thierry Leurent wrote:
Bonjour,
Le but de ce mail n'est pas de provoquer un troll qui se terminera en bataille
rangée, pour cela il y a d'autres sujets.
Le but est de me forger une opinion sur la solution proposée.
Le but est pouvoir argumenter sur les différentes options proposées que ce
soit au niveau technique ou au niveau coût de licences. Les licences pour un
futur développement ou licences des outils utilisés (Crystal Report par
exemple).
Précisions :
Ma boite n'est pas sensible à l'Open-Source, mais devient sensible aux
standards et à la portabilité Elle a eu de mauvaises expériences avec du tout
Microsoft.
Voici le problème :
Afin de remplacer et d'améliorer une application Dbase/Excel/Utilisateur. Ma
boite a lancé un appel d'offre pour réaliser une nouvelle version de cette
application basée cette fois sur Oracle.
Pq Oracle ?
C'est "gratuit" ou presque, vu le nombre de serveurs Oracle existant dans la
boite pour d'autres applications et la taille de notre DB (quelques GB). Ça
ne nous coûtera rien.
C'est connu, il y a des DBA Oracle et des développeurs Oracle la gestion et de
futurs petits développements.
Il y a 3 types d'utilisateurs :
Les managers (modif du schéma logique de la DB, Devel, ....)
Les gestionnaires qui introduisent les données dans la base.
Les autres qui ne font que de simples consultations.
L'alimentation de la base se fera essentiellement via des fichiers textes.
Quelques écrans de saisies manuelles o de mise à jour manuels sont à prévoir
mais c'est au cas ou.
Les consultations : Ce sont des "select" prédéfinis qui seront consultables à
l'écran, imprimables et exportables en csv.
Ce sont des fichiers interfaces prédéfinis csv ou longueur
fixe.
Le rapport : C'est un document .doc (obligatoire) qui est le merge entre
un "modèle" .doc et des données extraites de la base ou se dérivant de
données extraites de la base (exemple : si sexe = F alors Madame sinon
Monsieur).
Il a été demandé une application simple, portable, robuste, facile à
installer, évolutive (Nouveaux Devel) et important le code nous appartient.
Une des solutions présentées.
Serveur Oracle pour la base, .NET 2 (C#) + Crystal Report pour la couche
application et la couche client, Word/VBA pour le rapport.
Nous avons rencontré la société qui propose cette solution.
Quand, j'ai parlé de portabilité Ils ont parlé de Java et ont justifié le
choix de .NET par rapport à Java en indiquant que Java était plus lourd,
moins aisé pour un développement rapide et surtout moins stable dans le
temps.
Ils ont parlé que d'un JDK/JRE à un autre des fonctions disparaissaient ou que
les appels changeaient. Donc une application développée avec le JDK 1.3 ne
pourrait pas être utilisée avec le JDK 1.5.
Quand j'ai parlé de technologies "WEB", j'ai eu
- Un "c'est trop compliqué il faut développer pour chaque browser". Pour les
technologies web en général. IE occupant 90 % des parts du marché (C'est pas
les derniers chiffres dont je me rappels mais bon)
Cf mon dernier post : carte d'Europe avec la pénétration de firefox
(septembre : moyenne > 20 %, max 39%).
http://www.xitimonitor.com/fr-FR/Technique/Firefox_Septembre_2006/index-1-1-3-52.html
C'est un argument ridicule, il faut suivre la norme w3c , point.
Requérir IE c'est faire fi de l'interopérabilité (et si on y réfléchit
bien, c'est finalement de la complicité , par inertie sans doute mais le
résultat est le même, et c'est très dommageable).
- Un "C'est du bête HTML", pas convivial. Pour les normes W3C.
- Un "C'est volatile (ça change tous 12 à 18 mois). AJAX !!! Berrrrrk !!!!
Vous voulez développer une application critique en AJAX ????? Mais vous êtes
fou !!!" Quand j'ai parlé d'AJAX.
Voici mes conclusions qui demandent vos commentaires et retours
d'expériences :
- Vu la complexité des "calculs" et des contrôles (Calculs basics et intégrité
référentielle), Je placerais tous cela au niveau DB. Donc la partie
application/client fait des appels à la DB et des "impressions".
Est-ce si compliqué que celà ? Investir dans un dévelopement basé sur
OSS plutôt que de payer une grosse licence + maintenance n'est-t-il pas
envisageable.
Est-ce que le format doc est vraiment le bon ? Si on ne doit plus éditer
le résultat, un PDF ferait mieux l'affaire et est générable facilement
par ex. à partir de html, lui-même facilement générable à partir des
donnée du query.
A propos de CR, je crois qu'il y a moyen de faire ce genre de chose, y
compris le mailing par ex. en interfaçant OO2 par script : pour moi
c'est vers cette solution d'avenir que je dépenserais de l'argent.
Il faudrait évidemment mieux évaluer les besoins, mais ce genre de
choses je le faisais déjà en perl il y a bien longtemps avec un prologue
PostScript que j'avais développé pour générer de la typographie riche
(je n'avais pas troff) -> depuis lors, il y a bien des possibilités pour
résoudre ce genre de problème.
J'ai même pu utiliser les fonctions de mon prologue pour piloter
directement une graveuse laser à partir d'un query (texte riche,
automatiquement balancé dans des frames variés) :
http://www.br.fgov.be/SCIENCE/INFORMATICS/apps/engraver/index.html
- .NET 2 n'est pas portable enfin pas encore son support dans Mono est prévu
pour la fin de l'année. Puis, il faut voir les bibliothèques utilisées.
Et c'est un piège lock-in (je ne crois pas à l'équivalence de mono).
- .NET est plus stable au niveau version que Java. Cela m'étonne mais je ne
connais pas les deux mondes donc je n'ai pas d'expérience concrète et vous ?
- .NET est plus souple que Java. Confirmation ?
- Crystal Report est l'idéal pour générer des documents à partir de base de
données et modèles.
- Le Web, c'est pas si pauvre que ça au niveau présentation. Même sans AJAX,
au pire on adapte un peu le code généré en fonction du browser (Transparence
des PNG par exemple). Connaissez-vous des sociétés qui fuient AJAX ?
- Un serveur applicatif engendrerait des coûts plus élevés au niveau licences
(CR par exemple).
Je crois qu'il faut aussi mettre dans la balance l'intérêt des 'effets'
par rapport à la transmission efficace de l'information.
Pour ma part, je préfère accorder plus d'importance à la lisibilité et
la simplicité du message qu'à son aspect 'arbre de noël'.
'au pire on adapte un peu le code généré...' : pour moi je m'en tiens au
standard reconnu par tous, en évitant les toutes dernières possibilités
et toute divergeance entre browser.
Rien de pire que de peaufiner un magnifique message sophistiqué, qui est
rejeté ou mal rendu par le browser du client.
Un exemple : la _home_ page d'une société qui demande la toute dernière
version de flash pour être visible -> si cela rate on n'a pas accès à
l'information du site. C'est profondément idiot.
Questions subsidiaires ?
- Quelqu'un connaît-il Microsoft Reporting Service ?
- Existe-t-il un "Crystal Report Like" Open-Source ? Pas forcement compatible.
Je crois mais je n'ai pas noté la référence -> un peu de google ?
J'avais transmis cette info à des collègues, donc je devrais pouvoir
retrouver cela au besoin.
En résumé, pour moi, implémenter une solution OSS en payant le service,
c'est un investissement, choisir une solution propriétaire c'est une
dépense (récurrente).
Que pensez-vous de la proposition suivante pour la couche application?
PHP 5 générant des pages xhtml et des css.
PHP 5 Triturant du XML-MSOffice pour le rapport normalement en .doc.
Cette solution pose au moins deux problèmes :
Comment lancer Word depuis PHP.
Je ne lancerais pas _SURTOUT PAS_ word : je génèrerais du HTML (facile)
ou du PS (avec mon prologue) et je convertirais au vol en PDF (facile).
Mais je conseillerais plutôt l'approche intégrée dans OO2.
Comment construire facilement de nouveaux rapports.
Probablement qu'avec un bon interface vers OO2, on a tout sous la main :
le query, le mailing, l'output en PDF.
Un autre rapport c'est simplement adapter visuellement le query et le
template à utiliser.
Acquérir ces compétances (payer un consultant), c'est s'ouvrir à
l'avenir, et c'est un bel exemple de ce que j'appelle un bon investissement.
De plus cela fait vivre des experts locaux plutôt que de grosses
sociétés étrangères.
Voilà mon avis à chaud, je suis curieux de voir d'autres solutions.
Bon we,
Alain
Merci
-----
Thierry Leurent
_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@lists.unixtech.be
IRC: chat.unixtech.be:6667 - #unixtech
NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
begin:vcard
fn:Dr Alain EMPAIN
n:EMPAIN;Dr Alain
org:Fac. Veterinary Med., Univ. of LIEGE;Molecular Genetics
adr:Sart-Tilman;;B43;LIEGE;;B-4000;Belgium
email;internet:[EMAIL PROTECTED]
tel;work:+32 4 366 4497
tel;home:+32 85 51.23.41
tel;cell:+32 497 70.17.64
x-mozilla-html:FALSE
version:2.1
end:vcard
_______________________________________________________
Linux Mailing List - http://www.unixtech.be
Subscribe/Unsubscribe: http://lists.unixtech.be/cgi-bin/mailman/listinfo/linux
Archives: http://www.mail-archive.com/linux@lists.unixtech.be
IRC: chat.unixtech.be:6667 - #unixtech
NNTP: news.gname.org - gmane.org.user-groups.linux.unixtech
