Frédéric Glorieux wrote:
> >>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 ?
>
Je ne suis pas un spécialiste du sujet, mais il me semble que c'est
précisément ce que permettent les préférences linguistiques des
navigateurs (on peut indiquer plusieurs langues) et la négociation de
contenu de ce bon vieux httpd (voir
http://httpd.apache.org/docs-2.0/content-negotiation.html)
>Personnellement google.com m'agace très fort lorsqu'il
>me redirige vers .fr
>
>
Je suis bien d'accord ;-)
> >>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 ?
>
>
Ah, cet empilement de casquettes sur la tête ;-)
Le "nous" ici désigne Anyware Technologies, la société qui me nourrit et
dont je suis le responsable R&D. <pub>La quasi-totalité des projets que
nous faisons utilise Cocoon, et nous faisons de la formation et du
consulting sur Cocoon et les technos associées</pub>
>>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.
>
La "CVSSource", puisque c'est en fait un protocole "cvs:" pour les URLs
dans Cocoon est disponible sur
http://www.cocoondev.org/projects/cvssource.html
Elle ne peut pas être chez Apache parce qu'elle repose sur un client CVS
en licence LGPL.
>Vous utilisez quoi pour vérifier les liens ?
>
>
Une petite tambouille maison basée sur le crawler de Cocoon :-)
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)
Received on Wed Sep 1 11:37:37 2004
