dev@xmlfr.org : liste de discussion des développeurs du site XMLfr
[dev@xmlfr.org] Re: [xhtml] Objectifs
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 30/12/2003 - 09:25
Bonjour,
On Tue, 2003-12-30 at 01:39, Frédéric Glorieux wrote:
> >>S'il s'agit d'un objectif il faut vérifier que les xsl passent sous
> >>mozilla (quelques limitations hors spec), et bien sûr que les
> >>transformations n'aient pas besoin de ressources serveur indisponibles
> >>en ligne.
> >
> >
> > Et également que cela présente un intérêt de faire réaliser la
> > transformation par le poste client ce qui n'est pas toujours le cas.
>
> J'en ai rencontré la pertinence lorsqu l'on manipule des DTD standard
> inaffichable (docbook, Dublin Core, BilbioML ...), cela permet au client
> de prendre un contact direct avec la source.
>
> En ce qui concerne la transformation de présentation des documents, je
> n'en suis pas un chaud partisan. Je préfère réserver au dynamique ce qui
> résulte d'une interaction avec le client (exemple, des résultats de
> recherche).
Oui, c'est à quoi je pensais en parlant de finalisation interactive sur
le poste client.
> Je ne suis plus abonné cocoon mais je serai pourtant très intéressé par
> l'avis de Sylvain là-dessus.
>
> Je ne l'ai pas encore fait car tout est trop simple dans cocoon, mais je
> persiste à considérer que la cache est une solution batarde. Je me
> serais contenté de l'idée initiale de cocoon 2.0 de garder des URLs
> compatible système de fichiers (laisser les paramètres pour
> l'interaction) et considérer qu'il s'agit d'une sorte de ant toujours à
> l'écoute qui me regénère un site statique à chaque modification des
> sources (ex: la version CLI). Cela devient très utile lorsqu'on produit
> des images ou des pdfs que l'on aimerait bien retrouver plus facilement.
Oui et non ;-) ...
Il est également intéressant de considérer Cocoon comme un middleware
qui permet de masquer la structure physique du site (qui peut être
amenée à changer) pour assurer la permanence des URIs ("cool URIs don't
change").
> Au fond, ça ne prendrait qu'un transformer qui écrirait le fichier à
> envoyer dans une sorte de répertoire build, reste à bien ciseler le
> sitemap pour qu'il teste si la ressource statique a été générée et si
> elle est à jour.
>
> > Sur XMLfr, nous manipulons fréquemment des canaux RSS pouvant être
> > volumineux et cela serait contre productif de les faire transformer par
> > le poste client.
>
> J'ai hâte de voir ça dans le SVN (c'est bien le nom ? J'ai découvert,
> est-ce une alternative http à CVS ?).
Oui. Entre autres avantages, subversion permet d'associer des propriétés
aux documents qu'il gère et gère également l'historique de ces
propriétés. C'est une fonctionnalité que nous utilisons abondamment dans
l'interface rédaction de XMLfr.
> Sur RSS, j'ai lu mais jamais
> pratiqué. Avec notre machinerie de requêtes SDX, nous parlons de "liens
> tarzan" qui effectuent des requêtes sur des mots clés indexés dans des
> champs communs à plusieurs documents (classiquement, auteur, sujet ...).
> C'ets bien pour ce genre de choses ?
Entre autres. Tous les indexes de XMLfr (articles, mails, ...) sont des
canaux RSS.
> > Je pense que l'architecture la plus souple serait une double
> > transformation (dégrossissage côté serveur et
>
> Prégénérer les agrégations ?
Et faire en sorte que si l'on affiche que les 20 derniers articles sur
la page d'accueil on n'envoie pas la liste complète des articles publiés
depuis début 2000...
> Pour des blog j'ai cru comprendre que
> certains se suffisent des ServerSideInclude. Il ne s'agit pas de s'y
> limiter, mais cela vaut peut-être la peine de ne pas trop s'éloigner de
> cette compatibilité (pourquoi pas un cocoon qui prépare mais ne répond
> pas ?).
>
> Si je comprends, la tête et le pied ne changent pas souvent, les mots
> clés d'un document ne changent pas après la rédaction mais la liste de
> documents sur un mots clé doit être mise à jour, pareil pour les
> actualités ?
Oui.
> affinage interactif côté client).
>
> de la présentation ?
Oui.
> des skins ?
Oui, mais également le fait (par exemple) de trier les articles (par
date, catégorie, auteur). C'est à creuser, mais je suis certain que l'on
doit pouvoir améliorer l'ergonomie du site de cette manière.
Eric
> >
> > Eric
--
Have you ever thought about unit testing XSLT templates?
http://xsltunit.org
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
|
