dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] Re: Premiers pas avec Cocoon
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 20/12/2003 - 15:46
On Sat, 2003-12-20 at 14:43, Sylvain Wallez wrote:
> Eric van der Vlist wrote:
>
> >Bonsoir,
> >
> >En parallèle avec les travaux sur la structure de la page, j'ai
> commencé à installer Cocoon et ai deux questions à ce sujet.
> >
> >1) Toutes les listes d'articles de XMLfr sont des canaux RSS qui pour
> l'instant sont générés en batch en utilisant Ant et quelques tâches
> spécifiques. Est-il judicieux de faire gérer cela par Cocoon?
> >
> >J'ai fait un premier essai en utilisant le pipe suivant :
> >
> > <map:match pattern="decid.rss10">
> > <map:generate type="directory"
> src="/home/apache/xmlfr/remote/pages/actualites/decid">
> > <map:parameter name="include" value="^[0-9]*-[0-9]*\.xml$"/>
> > <map:parameter name="sort" value="name"/>
> > <map:parameter name="reverse" value="true"/>
> > </map:generate>
> > <map:transform src="stylesheets/rss/dir2rss.xsl">
> > <map:parameter name="layout"
> value="../../layouts/rss/decid.rss10"/>
> > <map:parameter name="directory"
> value="/home/apache/xmlfr/remote/pages/actualites/decid/"/>
> > </map:transform>
> > <map:transform type="encodeURL">
> > <map:include-name>rdf:li/@rdf:resource</map:include-name>
> > </map:transform>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> >Le résultat est à affiner (la transformation encodeURL ne semble pas
> fonctionner) mais vous pouvez le consulter à l'adresse
> http://beta.xmlfr.org/decid.rss10
> >
> >
>
> Le encodeURL sert à ajouter l'identifiant de session sur les URLs avec
> un ";jsessionid=xxxx" lorsque c'est nécessaire, c'est à dire
> lorsqu'une
> session existe (à priori non nécessaire pour de la publication comme
> c'est le cas ici) et que le navigateur ne supporte pas les cookies.
>
> Quel encodage est nécessaire pour les URLs?
Avec XT, j'utilise actuellement les appels Java suivants :
jurle:encode(jstring:toLowerCase($keyword))
où jurle est affecté à la classe java.net.URLEncoder et jstring à la
classe java.lang.String.
Je peux chercher à faire la même chose avec Saxon ou Xalan, mais dans la
mesure où aucun des deux n'implémente la fonction ESXLT str:encode-uri,
cela rendra les transformations moins portables.
Est-ce que cela justifie l'écriture d'un "tranformer" qui ferait cela?
Il y a sans doute d'autres "ajustements" de ce type qui pourraient être
pris en compte par ce "transformer". Par exemple, le fait de masquer les
adresses email pour les rendre moins facilement aspirables...
> >Le document résultant est gros (plus de 500K) mais cela semble rester
> assez rapide, du moins quand le résultat est en cache.
> >
> >
>
> Dans ce pipeline, le coût principal de contrôle de la validité du
> cache
> vient du directory-generator : il doit régulièrement recontrôler que
> les
> fichiers n'ont pas changé. Par défaut, la période est de 1 seconde,
> mais
> on peut la changer avec un <map:parameter name="refreshDelay"
> value="10"> pour, par exemple, 10 secondes. Dans le cas de XMLfr, le
> contenu n'évolue pas en temps réel et on peut donc augmenter cette
> valeur (quelques minutes ?), ce qui évitera de charger le filesystem
> inutilement pour constater que rien n'a changé.
Oui, cela semble une bonne idée!
> Je suppose que dir2rss.xsl utilise la fonction document() pour aller
> piocher dans les documents. Il peut être intéressant dans ce cas
> d'utiliser le XPathDirectoryGenerator qui, outre les informations sur
> les fichiers, peut aussi en extraire une partie.
Oui, pour l'instant j'ai juste adapté la transformation que j'utilise
actuellement en batch, mais j'ai également commencé à jouer avec
XPathDirectoryGenerator...
> >Ce n'est qu'une partie de la mécanique autour de RSS : ce canal sera
> ensuite combiné aux autres canaux pour donner une vue globale et
> divers résumés (reprenant uniquement les derniers articles seront
> produits sous plusieurs formats).
> >
> >Est-il réaliste de s'appuyer sur Cocoon pour gérer des documents de
> cette taille et comment peut-on utiliser au mieux le cache dans ce
> cas?
> >
> >
>
> Oui, c'est réaliste, et d'autant plus que le cache peut conserver le
> résultat sous forme XML (un "dump" des événements SAX), beaucoup plus
> rapides à restituer que de parser un fichier XML produit par Ant.
OK.
> >2) Je voudrais donner la possibilité d'uploader les essais de pages
> et ai commencé à faire quelque chose en ce sens :
> >
> > http://beta.xmlfr.org/tests/pages/
> >
> >au moyen des pipes suivants :
> >
> > <map:match pattern="">
> >
> > <map:aggregate element="doc">
> > <map:part src="index.xml"/>
> > <map:part src="cocoon:/dir"/>
> > </map:aggregate>
> >
> > <map:transform src="../../stylesheets/tests/index.xsl"/>
> >
> > <map:serialize type="html"/>
> > </map:match>
> >
> > <map:match pattern="dir">
> > <map:generate type="directory" src=".">
> > <map:parameter name="include" value="^.*\.html?$"/>
> > <map:parameter name="sort" value="name"/>
> > <map:parameter name="reverse" value="false"/>
> > </map:generate>
> > <map:serialize type="xml"/>
> > </map:match>
> >
> >
> >A partir de là, comment puis-je traiter les uploads?
> >
> >D'après ce que je comprend de
> http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithCocoon2.1, il
> faut soit utiliser XSP soit écrire une action pour cela. Est-ce le
> cas?
> >Si oui, n'y a t-il pas des actions "standards" pour le faire? Cela
> semble être un besoin assez générique!
> >
> >
>
> L'upload est un besoin générique, et Cocoon gère tout seul
> l'extraction
> des attachements dans une requête multipart. Ce qui est moins
> générique,
> c'est ce qu'on fait du fichier reçu.
>
> Maintenant, il est vrai qu'une utilisation courante va être de stocker
> les fichiers reçus dans un répertoire. J'ai donc écrit le pipeline
> suivant :
>
> <map:match pattern="upload">
> <!-- est-qu'un fichier a été envoyé ? -->
> <map:act type="resource-exists" src="upload://uploaded_file">
> <!-- oui : on le copie dans "dir" :
> - le protocole "upload" va chercher dans les fichiers envoyés
> - {request-param:uploaded-file} donne le nom du fichier -->
> <map:act type="copy-source" src="upload://uploaded_file">
> <map:parameter name="dest" value="dir/"/>
> </map:act>
> <!-- construction (éventuelle) de la page de réponse lorsqu'un
> fichier a été envoyé -->
> </map:act>
> <!-- construction de la page de reponse si pas de fichier ou tout le
> temps si on a pas de page spéciale lors de l'envoi d'un fichier. -->
> </map:match>
>
> Et là, problème : l'action "copy-source" est un peu stupide, parce
> qu'elle ne supporte pas un répertoire comme destination (honte sur
> moi,
> j'en suis l'auteur). Je viens donc de la corriger, mais ça veut dire
> qu'il faut travailler avec le Cocoon du CVS, où mettre à jour
> localement
> les fichiers sources impliqués (il y en a 2).
OK, je vais essayer cela.
> A noter aussi, l'action "copy-source" n'est pas déclarée de base dans
> la
> sitemap (c'est une petite nouvelle dans la 2.1.3), et il faut donc
> ajouter la déclaration suivante dans map:components/map:actions :
>
> <map:actions>
> <map:action name="copy-source"
> src="org.apache.cocoon.acting.CopySourceAction"/>
> </map:actions>
OK.
> >Merci pour vos conseils!
> >
> >Eric (débutant Cocoon)
> >
> >
>
> Eh, pour un débutant, c'est pas mal !
Merci!
Eric
> Sylvain
--
Curious about Relax NG? Read my upcoming book online.
http://books.xmlschemata.org/relaxng/
Upcoming XML schema languages tutorial:
- Santa Clara -half day- (15/03/2004) http://masl.to/?J24916E96
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
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
|
