laurent.duretz a écrit:

nicolas a écrit:

Je ne sais pas où tu cherches de la documentation mais tu peux te baser sur le guide de XulPlanet.com traduit par xulfr.

Je pars très souvent de Wikipedia qui est tout de suite très théorique.

Tu 'étonnes que tu ne comprennes pas trop où l'auteur veut en venir! :-)

laurent.duretz a écrit:

Une question quand même, utiliser le RDF à son plein potentiel signifie utiliser/redévelopper une classe de lecture de fichier RDF (surcouche de simplexml sans doute) ?

Non il suffit de construire un object DocDocument.

z0rglub a écrit:

nicolas a écrit:

quitte à revoir la structure des fichiers xml, plutôt que d'essayer de se créer sa propre dtd, pourquoi ne pas générer des fichiers rdf ? J'y vois pour ma part un réel avantage! J'espère vous montrer rapidement pourquoi.

Pourquoi pas faire du RDF. Enfin, j'aimerais en connaître le réel intérêt pour le cas du listing et de l'export, parce que la syntax est inutilement complexe pour le besoin.

Je ne suis pas sûr de bien avoir compris la raison d'être de l'export xml que tu as présenté mais si le but est de faire des exports de données structurées alors RDF est parfaitement adapté.
Par exemple, si on veut exporter les différentes catégories avec leur hierarchie alors là aussi c'est parfaitement adapté.

Et ce qui me pousse à dire que c'est aussi un bon format d'export de données est que c'est aussi un format d'import natif dans une extension firefox. Vois-tu où je veux en venir ?

Pour la question du volume, je pense que c'est un problème secondaire. Sur ton site distant, si tu as beaucoup de photos, ce sera le temps processeur qui sera le premier facteur limitant bien avant le volume du fichier. Il y a aussi la quantité de mémoire qu'on monopolise, et là c'est la méthode de génération du XML qu'il faut revoir.

Après avoir lu le tuto fourni par Nicolas (guide de xulPlanet.com), je pense pas que RDF soit le plus adapté à notre besoin. Sauf si on envisage de développer des plugin FFx autour de PhpWebGallery. Mais même dans ce cas, je pense que créer une feuille de style XSL pour transformer un document XML en RDF/XML est encore faisable.

La taille du fichier XML n'est pas un problème à lui seul. C'est le temps qu'il faudra pour le générer, la mémoire nécessaire pour le générer et le dumper en une seule fois et la mémoire nécessaire pour le lire et le parser, qui importent.

Pour le temps, il n'y a pas de solution. On peut toujours optimiser, générer le fichiers en plusieurs fois, le problème reste toujours lié à la taille de l'arborescence. Ce problème est aisément contourné par une réorganisation des arborescences. J'ai tenté de l'expliquer sur le Wiki.

De la même façon, une réorganisation de l'arborescence par l'utilisateur aténue le problème de mémoire.

Pour finir, ce post de zOrglub me plaît carrément !! zOrglub, as-tu une première ébauche de description de schéma STP ?

Autres questions à propos du format XML.

La fonction xml getChildren utilisée à ce jour et disponible dans include/functions_xml.inc.php me semble boguée.
Ce bug explique pourquoi :
-> Les <element>...</element> sont encapsulés dans un <root></root> qui ne délivre aucune information.
-> Les balises de répertoire sont incrémentales, ce qui n'est pas très "XML compliant".

La question que je me pose est :
-> Peut-on remplacer le parserx ml actuel par un autre bogué autrement :-) ?
-> Ces fonctions sont-elles appelées ailleurs que dans le parsing du fichier listing.xml ?

Dans mon développement local, j'arrive à travailler avec du xml bien écrit et lisible par les navigateurs (en ajoutant la balise </informations> à la fin), mais le problème des balises <dir> incrémentées m'empêche de travailler avec du xml valide.