>>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 ?
Je n'ai pas d'information de leur part mais considérons que vous êtes
danois, et qu'un document n'est disponible qu'en anglais et en allemand.
Lequel servir ? Personnellement google.com m'agace très fort lorsqu'il
me redirige vers .fr
>>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...
:o) bien sûr que non. Mais pour vous préciser le paysage, nos
utilisateurs demandent un "setup.exe" (en fait cela ne pose pas de
problème à faire avec inno setup).
>>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.
Nous avons étudié la question pour cacher des résultats de recherche, en
particulier parce que des auteurs d'application ont coutume de concevoir
leur page d'accueil avec des agrégations assez complexes de requêtes.
Difficile de trouver une solution générique avec un générateur XSP. On
préfère laisser faire apache.httpd
>>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éé).
Le lien relatif est en effet une grosse difficulté, nous sommes en passe
d'instituer quelque chose comme les wikiNames, et en fait, fournir
surtout les navigations par mots clés.
> Mais là, on tombe
> dans la problématique du CMS et du workflow et de la gestion des
> versions associée.
>
> Nous
avec Apache ?
> 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.
Pas mal ! Très pur, et CVS évite les renommages intempestifs et autres
réorganisations brutales. Vous utilisez quoi pour vérifier les liens ?
--
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)
Received on Wed Sep 1 10:46:06 2004
