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.

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 ?

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.

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 ?

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.

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:

nicolas a écrit:

rdf c'est du xml!

Oui, je l'avais bien noté mais les notions de triplet {prédicat, sujet, objet} ne sont pas évidentes dans les exemples que j'ai lu rapidement jusqu'ici.

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

nicolas a écrit:

vdigital a écrit:

Reste le pb de la quantité de bug de Php 5.
Ce n'est pas encore tout à fait stable.

mathiasm a écrit:

Mais ceci dit, l'hébergement du site de PWG (et donc la démo) sont en php4. Et comme la php5 manque encore un peu de stabilité, il faut rester prudent sur la "diffusion" du php5.

Pourquoi dites vous cela ? Vous vous basez sur quoi pour dire cela ?
Professionnellement parlant je suis passé à php5 sur le site de production depuis le mois de septembre 2005!

C'est ce genre de propos colporter à tout va qui freinent tout le monde et ralentit le passage massif à php5. php6 va sortir l'année prochaine (si le calendrier est respecté) et la majorité sera encore à développer en php4!

Désolé que mon propos, t'as heurté, Nicolas.
Mais je me base sur ma propre analyse des bugs ouverts (faite au mois de mai)...
Chacun s'exprime et tu as certainement raison de nous remonter les bretelles.

8-)