1630 sujets

Formats, encodage, internationalisation, XML

Création d'un CMS basé sur XML

Pages :
Bonjour,

Je suis graphiste, et je travail actuellement dans une société qui crée des site web standards à l'aide d'un CMS maison (PHP+XML+XSL=>XHTML+CSS). J'ai donc pu me familiariser à développer à l'aide du puissant XSL ! Mais (il y en a toujours un) ce CMS est premièrement propriétaire (je n'ai même pas le droit de voir les sources Smiley langue !) et je ne l'aime pas trop. Comme mon contrat se finit bientôt, je commence à réfléchir à me former sur un CMS basé sur XML bien comme il faut, et là PAF! cela est introuvable !

Pas démotivé pour un sous, j'ai commencé à imaginer un CMS qui utiliserait à fond XML, puisque apparemment cela est inexistant pour le moment alors que je suis persuadé qu'il y aurait des adeptes (si vous avez connaissance d'un projet existant ?). Je connais XSL, je connais aussi PHP (objet et tout), par contre javascript pas vraiment (mais je connais bien Action Script).

Je cherche donc à tout hasard, des gens qui seraient motivés pour m'aider dans ma tâche. Toute bonne volonté ayant des connaissances en PHP (objet) / JAVASCRIPT (utilisation de librairies) serait la bienvenue. Il s'agirait alors de créer un CMS opensource (si il y a des candidats, je vais créer un espace sur google code).

Voici un pdf expliquant une ébauche de ce que j'ai imaginé, dont tout est sujet à discussion : PDF

Edit: dans mes recherches, j'ai rencontré xform, étant sur Mac, je ne peux pas l'utiliser. Mais le CMS proposé ressemble en plusieurs points à ce système.
Modifié par warry (19 Feb 2008 - 23:16)
Administrateur
Bonjour,

Très intéressant et excellente initiative.
Les CMS axés autour d'XML ne sont pas courants, pour quelques raisons pratiques, dont il serait difficile de dresser une liste exhaustive.

J'ai moi-même travaillé sur deux bases de données XML, Exist et XIndice de la fondation Apache, qui ne m'ont pas laissé un souvenir impérissable (notamment en termes de performances), mais il est vrai que ce n'est pas mon domaine de prédilection.

L'arborescence est intriguante cependant, à première vue elle me faisait à un type MVC, tout comme RoR, CakePHP, Symphony, etc, ce qui semble être une structure adoptée désormais par la majorité des CMS. Puis je me suis dit que les termes contenu et affichage ne correspondaient pas totalement à Modèle et Vue... sauf erreur.

XSL serait donc requis, cela représente un petit frein au développement par des tiers, car il est encore peu maîtrisé (contrairement à l'écriture d'un template classique en php/xhtml pour lequel on trouve beaucoup plus de candidats).

Les points 4.1 et 4.2 me font également penser à Smarty.

Quid également des performances globales et de la mise en cache ? De la gestion multilangue ? De la réécriture d'URL ?

Voici quelques pistes de réflexion Smiley cligne

Il faut absolument penser à tout dès le départ, car l'écriture d'un CMS est extrêmement complexe si l'on veut satisfaire à tous les besoins, et on se retrouve assez vite coincé par un goulot d'étranglement inattendu. Je parle en connaissance de cause pour avoir développé un certain nombre de solutions utilisées sur de gros sites, avec des particularités assez variées entre chacun.

Je conseille de lire toutes les pages de présentation des meilleurs CMS existants et de réfléchir par avance à chaque point : comment sera-t-il réalisé, faut-il laisser une ouverture sur cette phase de développement pour pouvoir la compléter ensuite, etc.
Bonsoir,

De mémoire, le seul CMS que je connaisse qui utilise beaucoup XML est Pluxml.
Une recherche sur «xml-based cms» me donne quelques résultats mais je n'ai pas poussé plus avant.

Sinon, question: quel serait l'intérêt concret de ce CMS? J'ai lu ton PDF qui décrit les grandes lignes de ce que tu veux faire, mais j'ai du mal à voir ce que ça donnerait concrètement. Quel est l'usage de XML qui serait fait exactement?
- stockage des données?
- système de template (BDD ou fichiers XML de données -> format d'affichage)?
- modèles de contenu (modèle -> interface de saisie/gestion -> BDD ou fichiers XML)?
- tout ça à la fois?
xml/xsl est un concept super, seulement dans la pratique de mon point de vue il y a trop de frein aujourd'hui : performance, maniabilité...

En fait tout dépend de la quantitée de données, si il y en a peux, et que tu peux faire ça tout en xml sans base de donné (comme pluxml) alors c'est peut être une bonne idée. Mais si tu penses faire une base de donné je crois que c'est finalement plus compliqué :

bdd -> php -> xml -> xls alors qu'avec un moteur de template tu fais bdd -> php -> template

Je viens de finir un cms plutôt complet, je l'ai fait avec smarty et je doit dire que c'est vraiment incroyablement bien, c'est simple je ne lui trouve aucun défaut : très rapide, syntaxe très complète et aucun bug, a mon avis c'est aujourd'hui une meilleur solution que xml/xsl pour faire un cms.

Question développement c'est également très pratique, parce que tu gères tes requêtes et tes variables depuis le php donc tu n'as pas tout les problèmes de performances des cms classiques.

De plus question évolution tu es tranquille parce que tu peux toujours faire évoluer ton appli php et garder, mettre à jour tes formulaires smarty

Un des points les plus difficile d'un cms c'est la gestion des templates et du cache et la Smarty fait ça pour toi et le fais très bien.

Bonne nuit...
Modifié par matmat (20 Feb 2008 - 01:40)
Tout d'abord, merci d'avoir répondu Smiley smile
Et de manière collective je dirais que dans mon esprit, la base MySQL est facultative (les fichiers XML seraient directement stockés sur le serveur) et ce serait pour des sites de taille moyenne. J'avais lu un truc que je ne retrouve plus qui donnait des exemples de taille critique pour un site full XML avec les technologies actuelles (notamment en matière de recherche de données, et les modifications par lots). Une autre limite pourrait être les liens entre les contenus. Je ne me suis pas encore assez creusé la tête là dessus pour en faire une explication approfondie.

@dew :
Exist et XIndice utilisent des bases de données, je vais regarder tout de même mais je ne suis pas encore assez collé en design pattern (il semble en tous cas pour Exist que ce soit ça le principe).
Smarty ressemble en beaucoup de points en effet à l'idée proposée. Bien que ce soit bien plus qu'un simple éditeur de templates. Il semble très complet, mais pour le moment j'ai surtout regardé quelques pages sources pour me faire une idée.
J'ai des notions de MVC, mais ce qui m'intéressait surtout avec cette arborescence c'est que si l'on supprime le moteur, le site fonctionne toujours, et si l'on prend seulement le contenu, on peut très bien faire autre chose (du flash, des pdf...). Peut-être vaut-il mieux coller parfaitement à un modèle MVC ? Bien que si c'est le cas, il va me falloir pas mal de lectures avant de me mettre à coder.

Concernant les étapes, la réflexion, ce topic est en quelques sortes une prise de température (est-ce que des gens sont intéressés etc...), et des débuts de pistes.

@ Florent V. :
Je connais Pluxml, il est assez bien codé, light et vraiment accessible. C'est plutôt ce genre de projet que j'ai en tête qu'un framework complet.
En ce qui concerne le XML :
- Il servirait à stocker les pages dans la partie contenu (transformées en XSLT, dans la partie affichage)
- Permettrait de développer des templates (transformés en PHP, voire XSLT dans la partie moteur)
- L'utilisation de bases de données resterait possible, si l'on exporte les données vers un format XML.

@ matmat :
Oui je suis conscient des freins à l'heure actuelle, mais je pense que c'est aujourd'hui qu'il faut miser sur le XML pour en récolter les bénéfices bientôt. C'est une certitude que je peux avoir et qui peut ne pas être partagée par tout le monde.
Vous êtes deux à me parler de Smarty, je crois qu'il faut absolument que j'y jette un oeil. Question prise en main, tu en as pensé quoi ?
Ce que je trouve assez décevant finalement dans les CMS actuels, et que l'on ne peut pas créer un formulaire vraiment unique pour chaque page si on le souhaite. Soit on a un type blog avec un nombre de formulaires figés, soit on crée une table pour un type de page, mais il est totalement exclus de créer une table par page si par exemple on a des produits à présenter et qui n'ont pas le même nombre de caractéristiques.
Le principe est qu'à partir d'un template, avec des types de données prévus (les modules) on puis construire une page unique (autant de caractéristiques que l'on veut pour notre produit, et si un jour un produit similaire sort, on peut réutiliser la page). Le tout est dans une optique d'être le plus clair dans la sémantique, qui sera à mon avis le prochain grand enjeu de l'informatique : les ordinateurs devront être capables de comprendre ce qu'on leur dit. Je trouve que l'on utilise les BDD pour un peu tout, avec des liens entre les contenus qui ne sont pas forcément évidents. Si l'on prend l'exemple d'une page produit on a :
- une entrée dans une table avec : id, titre, prix, description, stock, description détaillée.
- plusieurs entrées dans une autre table avec les photos de la galerie.
- plusieurs entrées dans une base pour les commentaires
etc...
Alors que toutes ces entrées ne concernent qu'un seul et unique produit, que l'on peut donc sauvegarder dans un fichier XML qui présente uniquement ce produit. Après, c'est certainement plus simple de lier le constructeur au produit avec une base de données, encore que...

Pour en revenir à la comparaison avec PluXML : créer un système qui soit capable de lire des templates XML pour les transformer en formulaires dynamiques et enregistrer en XML soit un bon début. Un système ultra-light en somme.

Très heureux que cela fasse débat. Smiley smile Merci à vous !

W.
Modifié par warry (20 Feb 2008 - 14:36)
Florent V. a écrit :
Bonsoir,

De mémoire, le seul CMS que je connaisse qui utilise beaucoup XML est Pluxml.
Une recherche sur «xml-based cms» me donne quelques résultats mais je n'ai pas poussé plus avant.


J'ai bien sûr fait une recherche aussi, j'ai trouvé Haricow, qui est écrit en PHP5, mais qui semble au point mort. J'avais téléchargé le contenu du SVN, j'ai pas réussi à générer de pages, très buggé, très faillé. Il y avait aussi 2 ou 3 projets qui sont propriétaires.
Si tu cherches a faire un cms léger, alors une base de donnée xml c'est peut-être une trés bonne idée, c'est au dessus d'un certain volume de donnée que je me demande comment cela réagit, mais c'est peut-être une fausse idée, peut-être qu'en organisant bien les fichiers, genre un fichier "index.xml" et des fichiers "mon_article.xml" cela peut-être trés puissant.

L'avantage comme tu dis c'est la complète interropérabilitée avec js,pdf, pour ajax par exemple cela doit être très pratique, tu peux ainsi faire ton code sans et avec ajax avec la même source xml à la base.
Un autre avantage c'est que tu n'as plus besoin de moteur de template, vue que xslt en est un.

Il me semble que la question à résoudre serait a quel point xml peut être utilisé comme base de donnée, peut-être voir les retours d'utilisateur de pluxml, voir ouvrir un post sur leur forum. Si il n'y a pas d'obstacle majeur a ce niveau là alors le reste doit pouvoir ce régler au fur à mesure.

Pour le code de pluxml, il y un truc qui m' étonne, c'est le fait que les formulaire justement ne soit pas gérés par des templates (ce serait bien pourtant des beaux formulaires xslt) mais par un mélange php/html, je ne sais pas si c'est une très bonne idée, même cela ne me semble pas très propre, a mon avis il vaut mieux utiliser le modèle vue/contrôleur justement, avec des fichiers "actions" et des templates de formulaires.

Pour Smarty si tu veux essayer, c'est trés simple à prendre en main et bien documenté ( je te dis cette classe n'a aucun défaut... )
matmat a écrit :
Pour Smarty si tu veux essayer, c'est trés simple à prendre en main et bien documenté ( je te dis cette classe n'a aucun défaut... )

J'ai téléchargé un PDF, et c'est vrai que c'est bien. Ce n'est pas l'outil que je cherchais, puisque je cherchais un CMS, mais un framework c'est l'idéal quand on le maitrise bien !

matmat a écrit :
Si tu cherches a faire un cms léger, alors une base de donnée xml c'est peut-être une trés bonne idée, c'est au dessus d'un certain volume de donnée que je me demande comment cela réagit, mais c'est peut-être une fausse idée, peut-être qu'en organisant bien les fichiers, genre un fichier "index.xml" et des fichiers "mon_article.xml" cela peut-être trés puissant.

L'avantage comme tu dis c'est la complète interropérabilitée avec js,pdf, pour ajax par exemple cela doit être très pratique, tu peux ainsi faire ton code sans et avec ajax avec la même source xml à la base.
Un autre avantage c'est que tu n'as plus besoin de moteur de template, vue que xslt en est un.

Il me semble que la question à résoudre serait a quel point xml peut être utilisé comme base de donnée, peut-être voir les retours d'utilisateur de pluxml, voir ouvrir un post sur leur forum. Si il n'y a pas d'obstacle majeur a ce niveau là alors le reste doit pouvoir ce régler au fur à mesure.

Les API XML dans PHP sont sous les projecteurs depuis peu de temps (si l'on compare à SQL), gageons que celles-ci vont encore s'améliorer. Dans le même temps il faudra observer ce que Sun va faire de MySQL (et leur attachement aux standards) ! Si les bases MySQL font des progrès dans la sémantique, tout mon plan tombe à l'eau Smiley ravi !
Je vais me renseigner sur ces performances, et compte-rendu ici-même.
XSLT avec PHP : L a situation en 2002

Ce qui est dit : Mysql 120rq/s ; XSLT : 65rq/s
L'auteur compare le XSLT avec une utilisation de Smarty sans cache. Avec une bonne gestion du cache (un exemple) il y a fort à parier que le gain de performances peut-être significatif.

Le texte date un peu, et sachant que pour construire une page complète, il faut plusieurs requètes MySql, alors que la transformation XSLT est plutôt linéaire.
Modifié par warry (20 Feb 2008 - 17:03)
Sachant que Smarty avec cache c'est est peut prés un gain similaire que ce qui est décrit dans le document xsl cache, on en conclue qu'on arrive a des performances égales, ce qui est plutôt une bonne nouvelle pour ton projet.

Ce qui m'intrigue c'est quelle structure peut bien prendre une base de donné xml?

edit : une petite remarque, as tu penser a la possibilité d'utiliser perl pour le traitement du xml?
Modifié par matmat (20 Feb 2008 - 21:42)
matmat a écrit :
Sachant que Smarty avec cache c'est est peut prés un gain similaire que ce qui est décrit dans le document xsl cache, on en conclue qu'on arrive a des performances égales, ce qui est plutôt une bonne nouvelle pour ton projet.

Ce qui m'intrigue c'est quelle structure peut bien prendre une base de donné xml?

edit : une petite remarque, as tu penser a la possibilité d'utiliser perl pour le traitement du xml?

J'ai pensé à Java et Python, et je me suis dit que je connaissais déjà Php, et c'est plus répandu. Je ne connais pas Perl. (je suis graphiste, je le rappelle Smiley lol )
php est plus répandu, parce que les développeur français, peut-être par manque de documentation en français utilisent peu perl, c'est dommage parce que c'est vraiment super, par exemple pour créer et lire les fichiers xml. Ceci dit il doit y avoir des classes php genre celle là (il est toujours plein de bonnes ressources mister Simon Willison’s) pour écrire et lire du xml.

Ce que je me demande toujours c'est comment tu penses structurer tes fichiers xml.

Par exemple avec une base de donné si tu veux récupérer le titre et la description de tout les éléments d'un menu c'est simple, avec xml comment fais tu, tu ouvre tout les fichiers xml concerné si il y en a un par page, tu en fais un énorme?
Modifié par matmat (21 Feb 2008 - 00:45)
J'ai réfléchis à cela et voilà comment je vois la chose :

en XML : on cherche tous les fichiers XML d'une requête XSL, on charge l'url du fichier correspondante, et on affiche pour chacun les valeurs de balises.

en MySql : on cherche toutes les entrées qui matchent (SELECT), on affiche pour chacune d'entre elle le contenu des champs à sélectionner.

Cela n'ajoute qu'une étape sur un le fichier d'arborescence : "on charge l'url du fichier correspondante" << reste à savoir si cette étape est coûteuse ? Autrement dit : est-ce que avec l'API DOM, la foncion domxml_open_file() est coûteuse ?

En plus les pages sont directement rangées par catégories dans le fichier d'arborescence, donc la taille ne dois pas être un handicap puisque beaucoup de requêtes pourront être mieux ciblées que si elles avaient été dans un SQL (les entrées sont dispersées, rangées par ID).

Et pour gagner en rapidité, on peut inscrire à la fois sur le fichier, et à la fois dans l'arborescence des infos comme le titre, l'auteur la date (pour les menus, et en plus cela ajoute à la sémantique). L'information est redondante, mais qui ne coûte qu'à la modification finalement.

Avis perso : Je ne pense pas que le ratio performance entre MySql et XML soit un handicap. Certainement un peu moins rapide, et donc le moteur de cache est le choix déterminant.
Modifié par warry (21 Feb 2008 - 03:08)
a écrit :
est-ce que avec l'API DOM, la foncion domxml_open_file() est coûteuse ?

Il faudrait faire des tests, mais c'est possible que l'on soit surpris dans le bon sens, c'est peut-être pas beaucoup plus long que la lecture d'un fichier text qui est très rapide. Donc peut-être que finalement les performances ne sont pas si éloigné d'un sisteme sgdb classique au niveau vitesse et surement meilleur par contre au niveau de la consommation du cpu.

L'article que tu cites est intéressant mais pas très précis parce que l'on ne sais pas par exemple quelles requêtes mysql sont faites et quel fichier xml sont chargés, a mon avis si tu fais de requetes pleine de * sur des 50 colonnes contre un xml de trois lignes tu inverses les résultats...

Peut être qu'il faut justement ne pas comparer sur les même points et utiliser les avantages du xml la ou il est rapide, en quelque sorte sortir du modèle "requêtes" pour préférer un modele "contenu". Par exemple pour un page simple si on a un fichier menu et un fichier contenu cela peut être trés performant, donc il vaut surement mieux dupliquer l'information au niveau des xml plutôt que d'appeler 50 fichier.

imaginons un cas concret : une page d'accueil avec trois bloc: articles, services, produit.
la première requete xsl (si j'ai bien compris) charge le fichier d'arborescence et sort les liens vers les fichier voulus qui sont a leur tours chargés pour afficher dates titres et descriptions. ça fait donc le même nombre de fichier fichier xml a ouvrir que de requêtes mysql a a faire donc d'aprés l'article que tu cites c'est deux fois plus long, (sauf comme il n'y pas de moteur de template à faire tourner peut être qu'on s'y retrouve).

Mais on pourrais peut-être imaginer les choses autrement avec plus de fichiers xml, un fichier arborescences et des fichiers "menus" intermédiaire pour les grandes sections avec par exemple un fichier "articles.xml" (ou "products.xml" ) qui contiendrait la liste des articles avec la description. Donc plus besoin de charger tout les fichiers xml de chaques articles pour avoir la description on utilise ce fichier menu. Ce qui nous fait pour notre exemple de page d'accueil que 4 fichiers à charger. C'est un peu confus, mais l'idée est de profiter de la souplesse du xml par rapport a la structure rigide table / colonne. Evidement au moment de l'actualisation de l'article il faut modifier les trois fichier, l'arborescence, le menu et l'article, ce qui ne devrait pas être un problème.

Ce qui est également séduisant dans ce schéma c'est la démarche similaire parseur php / parseur javascript. Ce qui veut dire que l'on a pas comme en php/mysql/xhtml a produire d'un coté le code xhtml avec le moteur template et de l'autre le xml avec php (ou le "moteur" de template mysql->xml). Dans le cas de ce que tu proposes on utilise la même source : le xml. Cela peut être un énorme avantage de ton cms car il produirait des requêtes ajax facile a gérer et très rapide, puisque le xml n'est pas généré a la volée comme avec une base donnée.

Par rapport au cache, par expérience, c'est bien, même très bien, mais il faut pas compter dessus en ce disant pas grave si sa rame de toute façon il y a le cache. En effet le cache pose tellement de problèmes (mise a jour de toute l'arborescence, interface personnalisée en fonction des utilisateurs entre autre) qu'il faut souvent prévoir que le site puisse aussi bien tourner sans le cache.
Modifié par matmat (21 Feb 2008 - 07:53)
matmat a écrit :

Mais on pourrais peut-être imaginer les choses autrement avec plus de fichiers xml, un fichier arborescences et des fichiers "menus" intermédiaire pour les grandes sections avec par exemple un fichier "articles.xml" (ou "products.xml" ) qui contiendrait la liste des articles avec la description. Donc plus besoin de charger tout les fichiers xml de chaques articles pour avoir la description on utilise ce fichier menu. Ce qui nous fait pour notre exemple de page d'accueil que 4 fichiers à charger. C'est un peu confus, mais l'idée est de profiter de la souplesse du xml par rapport a la structure rigide table / colonne. Evidement au moment de l'actualisation de l'article il faut modifier les trois fichier, l'arborescence, le menu et l'article, ce qui ne devrait pas être un problème.

Ce qui est également séduisant dans ce schéma c'est la démarche similaire parseur php / parseur javascript. Ce qui veut dire que l'on a pas comme en php/mysql/xhtml a produire d'un coté le code xhtml avec le moteur template et de l'autre le xml avec php (ou le "moteur" de template mysql->xml). Dans le cas de ce que tu proposes on utilise la même source : le xml. Cela peut être un énorme avantage de ton cms car il produirait des requêtes ajax facile a gérer et très rapide, puisque le xml n'est pas généré a la volée comme avec une base donnée.

Par rapport au cache, par expérience, c'est bien, même très bien, mais il faut pas compter dessus en ce disant pas grave si sa rame de toute façon il y a le cache. En effet le cache pose tellement de problèmes (mise a jour de toute l'arborescence, interface personnalisée en fonction des utilisateurs entre autre) qu'il faut souvent prévoir que le site puisse aussi bien tourner sans le cache.

C'est vrai qu'une séparation des arborescences ne serait pas un luxe ! J'avais pensé à un seul fichier, au cas l'on veuille lui changer de place, mais en même temps on ne met pas un article dans produits sur un coup de tête, ensuite cela n'est pas beaucoup plus complexe à développer. Du coup, il faut un fichier XML racine, puis des enfants. C'est finalement assez évident comme modèle, je sais pas pourquoi je me suis entêté avec un seul fichier.

En ce qui concerne Ajax, comme j'ai pu le marquer plus haut, je ne suis pas expert mais par contre je fais pas mal de Flash, donc c'est une des raisons qui me poussent à vouloir un tel CMS.

Oui je sais bien qu'il ne faut pas se baser sur le cache, mais en ce qui concerne la génération des menus le cache a tout de même un très grand rôle.

Je vais me renseigner de suite sur les temps d'ouverture de fichiers XML, si cela est concluant, je pense que je pourrais attaquer la modélisation du projet : poser toutes les questions etc...
Modifié par warry (21 Feb 2008 - 10:44)
Si tu connais bien Action Script, tu ne devrais pas avoir de mal avec javascript. De toute façon flash/xml c'est super aussi...
matmat a écrit :
Si tu connais bien Action Script, tu ne devrais pas avoir de mal avec javascript. De toute façon flash/xml c'est super aussi...

Ce qui m'embête le plus c'est les interprétations aléatoires suivant les navigateurs Smiley biggol

Toujours pas de réponse précise sur l'ouverture de fichier XML. J'attends.
A mon avis avec ce code tu devrais pouvoir faire des test :



function microtime_diff($a,$b) {
  list($a_micro, $a_int)=explode(' ',$a);
  list($b_micro, $b_int)=explode(' ',$b);
  if ($a_int>$b_int) {
    return ($a_int-$b_int)+($a_micro-$b_micro);
  }elseif($a_int==$b_int) {
    if($a_micro>$b_micro){
      return ($a_int-$b_int)+($a_micro-$b_micro);
    }elseif($a_micro<$b_micro){
      return ($b_int-$a_int)+($b_micro-$a_micro);
    }else{
      return 0;
    }
  }else{ // $a_int<$b_int
    return ($b_int-$a_int)+($b_micro-$a_micro);
  }
}

$start_time = microtime();

domxml_open_file('./feuille.xml');

$end_time = microtime();
$execution_time = number_format( microtime_diff($start_time,$end_time),4);

echo $execution_time*1000;


A noter qu'il y beaucoup plus simple comme fonction microtime_diff, mais c'est la seule qui t'assure toujours un résultat coherent


Edit : J'ai fait quelque test http://www.smart-com.com.mx/bench/ , et il semble que se soit plus le poid du fichier que le nombre du fichier qui soit important, en gros ouvrir 10 fichier de 3k c'est presque pareil que un de 30. un fichier de 300k mettras pas tout a fais 10 fois plus de temps a ce charger met 8 fois plus environs.

Ce texte est incomplet il faudrait maintenant tester domxml_xslt_stylesheet_file() et $xslt->process($xml) pour pouvoir avoir un bon aperçut de situation. Ce serait pas mal cela permettrais de coder en conséquence.

on peut quand même conclure que la fonction domxml_open_file ne pose aucun probléme de performance (13ms pour 370k c'est pas grand chose, 370k de xml ça fait quand même un paquet d'info...) à voir donc le traitement xslt.
Modifié par matmat (21 Feb 2008 - 20:36)
Ouverture d'un XML : 0.0093
Connexion à MySql : 0.0049

J'ai fait des mesures avec 1000 entrées, mais j'ai fait une bétise dans ma requete XML. Je recommence.
Modifié par warry (21 Feb 2008 - 20:37)
ce serait possible d'avoir le détail de comment on été effectués ces tests?
Modifié par matmat (22 Feb 2008 - 00:15)
Pages :
Sujet clos
Aller à