dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] Re: Cocoon, retour d'expé riences
From: Sylvain Wallez (sylvain.wallez@anyware-tech.com)
Date: 31/08/2004 - 08:25
Frédéric Glorieux wrote:
>Bon retour !
>
>
>
>>Si je comprends bien, le pipeline écrit le fichier correspondant à l'URL
>>demandée en plus de le renvoyer au navigateur ?
>>
>>
>
>Oui. Et c'est aussi à cet endroit que je (vais) glisser l'indexation de
>manière à avoir les docs cherchable en temps réel. C'est ce point qui
>justifie de parler de cela ici, car je me demandais comment xmlfr
>comptait procéder pour indexer ses docs en contexte cocoon.
>
>
>
>>C'est une approche intéressante, mais qui ne convient que si le même
>>contenu est renvoyé pour tous les appels d'une URL. En particulier, ça
>>interdit la négociation de contenu pour un site multilingue.
>>
>>
>
>On pourrait glisser toute sorte de finesses, comme les pompeurs de sites
>(ex: nom de fichier avec MD5 des paramètres), mais comme je travaille
>dans le cadre d'une application définie, les tuyaux sont contrôlés. Et
>d'ailleurs, est-il pertinent de cacher une page résultant de
>l'interation utilisateur ?
>
Oui, c'est intéressant, parce que plusieurs utilisateurs peuvent avoir
la même interaction avec le serveur. Bien évidemment, la clé dans le
cache doit prendre en compte les éventuels paramètres discriminants,
mais aussi les éléments non présents dans la requête comme le groupe
d'autorisations qui conditionne le résultat produit. Le cache Cocoon
offre toute la souplesse nécessaire pour ça.
>Pensez à une application de type Forrest, les
>rédacteurs peuvent surveiller leur site, et il s'écrit en même temps.
>
>
Mmmh... je ne vois pas le problème pour le document considéré
unitairement (fichier changé ==> cache invalide). Par contre, il est
vrai qu'il peut y avoir des problèmes de cohérence globale (par ex. un
lien sur un document qui n'a pas été encore créé). Mais là, on tombe
dans la problématique du CMS et du workflow et de la gestion des
versions associée.
Nous avons fait des CMS basés sur CVS où ce que voit un visiteur anonyme
est un certain tag dans le repository CVS. Les rédacteurs par contre
travaillent (et voient) la dernière version, et le processus de
validation déplace le tag de publication après contrôle d'intégrité de
l'ensemble des documents.
>Nous avons beaucoup de problèmes de déploiement serveur parmi nos
>partenaires, un statique généré et précisément structuré fini par être
>la seule solution viable.
>
>
Ok, mais ça m'a plus l'air lié à des problèmes d'infrastructure qu'à des
problèmes de cache Cocoon...
>Le multilinguisme est pour nous un problème tellement critique qu'il a
>fallu le régler à la source. Considérez l'exemple de ce site hautement
>concerné par la diversité des langues
>
>http://europa.eu.int/index_fr.htm
>
>
Pourquoi n'utilisent-t-ils pas la négociation de contenu pour proposer
directement la page dans la langue de l'utilisateur ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
--
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/08/2004 - 08:32 UTC
webmaster@xmlfr.org
|
