dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] xsp ? était Re: [xhtml] Objectifs
From: Frédéric Glorieux (frederic.glorieux@ajlsm.com)
Date: 31/12/2003 - 15:53
[XSP et taglibs]
[XSP et cache]
[XSP et XSL]
-------------
[XSP et taglibs]
>>>>Je connais peu SDX, mais j'ai cru comprendre qu'il reposait
beaucoup sur les XSPs,
Oui, trop peut-être. Nous n'avons pas encore pris le temps de donner un
accès sitemap aux API. Ce n'est pas un problème technique mais comptable
(qui veut payer ce temps ?).
Mais lorsqu'on parle xsp, disons plutôt taglib, à un degré de complexité
d'ailleurs discutable. En fait, nous en arrivons cahin/cahan à une
syntaxe autonome. Je serai très intéressé par l'expérience de Sylvain
sur le contrôle du développement de la sitemap.
Je pense tout de même que cette approche à son intérêt. Il me semble que
<agregate/> est le cas limite de là où le sitemap ne doit plus aller.
Ensuite, pour construire le xml que l'on veut, xsp+taglib est un
principe formidable.
> J'ai tendance à préférer l'idée de générateurs spécifiques à celle de
> XSP, mais c'est peut-être un mauvais préjugé!
N'oubliez pas que l'on trouve plus vite des bidouilleurs de fichiers XML
que des développeurs de classes JAVA. Personnellement, pour les actions
par exemple, cela ne m'amuse pas de compiler pour trois lignes de
logique qu'il faut patiemment tester, je fais des actions xsp
<http://wiki.cocoondev.org/Wiki.jsp?page=XSPAction>
>>On l'utilise principalement lorsqu'il faut "XMLifier" des choses
>>diverses comme des requêtes de SQL, des requêtes Lucene (encore qu'il y
>>ait un "SearchGenerator" pour ça) ou n'importe quel résultat d'une
>>logique Java.
oui !
---------------
[XSP et cache]
>Je n'ai pas assez d'expérience autre que notre Cocoon/SDX pour avoir un
>>avis objectif sur la chose. Par contre j'ai souvent eu le besoin de
>>donner une vue statique sur une collection, il y a aussi le problème des
>>performances Cocoon. D'où cette envie de donner le plus possible au
>>statique, et de ne demander que le minimum au dynamique.
> Ne
> complexifions pas toute l'architecture à partir d'hypothèses non
> vérifiées sur les performances.
Je concède que la performance est un argument de mauvaise foi. Par
contre la récupération d'un statique propre de choses générées par
cocoon (png ou pdf par ex) est je crois très utile à plus d'une
organisation (ex: demo hors ligne, zip à télécharger...).
> Plusieurs réponses à ces soucis de performances, de la philosophie aux
> mains dans le cambouis :
>
> "Premature optimization is the root of all evil" (Donald Knuth).
Je ne connaissais pas <http://www-cs-faculty.stanford.edu/~knuth/>, un
livre à lire. Je pense que j'utliserai aussi cette phrase pour justifier
mes erreurs de design quand je pars vers l'usine à gaz.
> Et puis tu as
> peut-être de mauvais souvenirs des performances de Cocoon 1.x qui
> étaient effectivement pas terribles...
C'est oublié, et j'en suis bien heureux. Mais nos utilisateurs combinent
des pages d'accueil avec des requêtes de plus en complexes qui
commencent à fatiguer les serveurs (mais en France en tous cas, il coûte
parfois moins de payer de la machine que du développement).
> [xsp] qui ne sont
> pas naturellement cachables (bien qu'on puisse le faire).
J'ai étudié cette possibilité
<http://wiki.cocoondev.org/Wiki.jsp?page=XSPCachingWithCocoonHEAD> mais
comme SDX n'est toujours pas 2.1...
> Au delà du cache interne de Cocoon, les performances et la tenue en
> charge sont grandement améliorées en mettant en frontal de Cocoon un
> serveur httpd Apache avec le mod_cache. Les pipelines Cocoon peuvent
> spécifier une date d'expiration pour leur production, et le cache de
> httpd ne fera aucune nouvelle requête à Cocoon tant que le délai
> d'expiration ne sera pas atteint.
>
> Et pour obtenir des performances encore plus élévées, on peut faire une
> utilisation conjointe astucieuse de mod_rewrite et Cocoon : pour une URL
> donnée, on commence par regarder si le fichier correspondant existe. Si
> oui, on le renvoie. Si non, on route la requête sur Cocoon, qui renvoie
> le résultat *et* l'enregistre sur disque. Au coup d'après, on ne lui
> redemande donc rien. Par ailleurs, chaque modification de la base
> documentaire entraine l'effacement des fichiers sur disque qui en
> dépendent (c'est le point délicat de cette approche). C'est expliqué sur
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104452461431897&w=2
ça c'est de l'info d'administration !!! ça ne vaut pas un howto avec
download sur xmlfr ? Complètement à l'inverse, je fais tourner un cocoon
sur CD-ROM (avec 0% d'install).
-----------
[XSP et XSL]
> Voilà. Tout ça pour dire qu'au moins dans un premier temps, il ne faut
> pas se contraindre dans l'utilisation de Cocoon ;-)
Contraindre ? ou construire ? On en voit trop qui servent un outil (ou
un langage), plutôt que de s'en servir... Mais il semble qu'ici nous
faisons exactement le contraire, en toute indépendance, c'est ce qui
rend l'entreprise très formatrice.
>>>Hmmm... A ce sujet, j'aimerais éviter au maximum les XSPs et privilégier
XSLT qui est plus portable et plus conforme à l'idée que je me fais
d'un système de publication XML...
>>XSLT transforme le contenu initial qui peut venir d'un fichier, une XSP
>>ou n'importe quelle autre source XML. La confusion est toutefois
>>possible si on utilise les extensions Java depuis XSLT : la feuille de
>>style devient alors une sorte de langage de script.
>
>
> Dans le cas général (hors Cocoon), je pense que ce n'est pas
> nécessairement un mal si on isole cette partie "scripting" dans des
> transformations qui ne font que cela.
Sur ce point j'ai reçu des excellentes leçons de cocoon. Je ne sais pas
si c'est encore comme ça avec xalan-cocoon, mais avec une XSL qui
utilisait simplement la fonction document(), j'ai découvert dans les log
qu'il y avait un hit à chaque fois que j'utilisais la variable sensée
contenir le nodeset du doc. On est définitivement passé à Saxon.
Sur le scripting, j'étais contre par principe, mais présenté ainsi (avec
une xsl détachée), non seulement cela se défend, mais cela renforce
encore plus l'intérêt de s'investir en XSL. Ceci dit, j'attendrai encore
un peu avant d'y mettre du javascript IE :-)
Après, si en environnement me propose une syntaxe XSP pour en tirer
rapidement profit, je préfère passer du temps sur la réflexion éditoriale...
--
Frédéric Glorieux
AJLSM, ingénieur documentaire
<frederic.glorieux@ajlsm.com>
tel +33 (0)1 49 54 22 22
fax +33 (0)1 49 54 21 80
http://www.strabon.org
EUMEDIS - Strabon - WP7 - formation/training
Maison des Sciences de l'Homme
54 Boulevard Raspail
75006 PARIS
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 31/12/2003 - 17:02 UTC
webmaster@xmlfr.org
|
