sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sdx-users] Urls et plan de nommage


From: Emmanuel Bégué
Subject: [sdx-users] Urls et plan de nommage
Date: Wed, 7 May 2003 10:04:31 +0200

> -----Message d'origine-----
> De la part de Pierrick Brihaye
> Envoyé : mercredi 7 mai 2003 08:57


> Si tu nous en disais un peu plus sur ton plan de nommage de fichiers, on
> pourrait peut-être t'aiguiller vers le matcher adéquat (v. quand même la
> doc Cocoon à ce sujet). A vue de nez, tu auras plutôt besoin d'un
> matcher basé sur des expression régulières au lieu du matcher par défaut
> qui matche sur des jokers.

A dire vrai, pour l'instant l'appli, toute imparfaite qu'elle soit, va
rester comme elle est (dans un premier temps): elle fait ce qu'on lui
demande
de faire, et les améliorations auxquelles je pense seraient assez
"conceptuelles"
dans le sens où elles n'amélioreraient pas le service aux utilisateurs (sauf
à permettre le highlight, mais encore faudrait-il pour cela appeler les
documents directement depuis SDX, et je ne suis pas sûr qu'on pourrait le
faire en intégrant le contrôle d'accès qui est pour l'instant nécessairement
externe).

Donc mon plan de nommage de fichiers reste assez abstrait: je veux prévoir
l'avenir et pouvoir gérer des cas différents.

Mais il me semble que si la sitemap permet de convertir à la volée des urls
virtuelles en urls réelles c'est ce dont j'ai besoin; concrètement si je
peux
stocker des urls "logiques" du genre
http://serveurCocoon/nature-du-fichier/organisme/vraie-adresse/fichier.xml
et les transformer à la volée ("at click time"?) en
http://serveurFichiersToto/vraie-adresse/fichier.xml
en fonction de nature-du-fichier et de organisme ou de n'importe quel
autre paramètre inscrit dans l'url, je couvre tous les cas possibles et,
surtout:
- sans stocker d'information de stockage dans les XSL (ce qui me gêne
assez, d'un point de vue "théorique")
- sans avoir à réindexer sous prétexte d'un changement physique
des fichiers (ce qui est l'objectif principal).

D'un autre côté, le stockage des urls virtuelles peut se faire n'importe
où; on pourrait dire tout aussi bien:
http://serveur/redir.php?file=fichier.xml&adress=adresse&org=organisme

Dans ce cadre, est-ce que Cocoon présente un avantage distinctif (autre
qu'être déjà la plate-forme SDX) par rapport à n'importe quel autre
langage de script capable de renvoyer un header "Location:"?

Par ailleurs, lorsqu'on demande à SDX d'afficher un document, il fait
un "include" en quelque sorte? Est-ce que le nombre de redirects peut
finir par être un problème?

Cdt,
EB





reply via email to

[Prev in Thread] Current Thread [Next in Thread]