XYL sans données, c'est du XSLT. La suite va être plus surprenante. Le Y de XYL renferme toutes les astuces.

J'ai dit depuis le début que XYL était un mélange de XSLT, XBL et XUL. On a déjà la première étape qui est XSLT (transformation d'un arbre XML vers autre chose). La suite c'est XBL grâce au Y de XYL, le yielding. Ça va permettre de créer des composants « à la volée » et les réutiliser. Pas encore sûr de la syntaxe, mais on aurait un truc du genre (je dévoile une partie de mes secrets hein ) :

<yield name="article" source="?">
  <section value="?title" />
  <paragraph value="?description" />
</yield>

<article value="?foo/bar/" />

<yield name="articles" source="?*">
  <article value="??" />
  <separator />
</yield>

<articles value="?gna/gna" />

L'idée c'est quoi ? <yield> permettrait de créer un composant qui se fixe une racine virtuelle en fonction des données qu'on lui donne. <article> est appelé en donnant les données ?foo/bar/, et <article> va filtrer (grâce à @source) sa racine, ici ? donc la racine normale (on oublie cette notion pour l'instant). Il faut juste comprendre qu'on sélectionne un sous-ensemble parmi les données qu'on nous donne.
Du coup, pas de problème de vues, de sous-vues ou de truc à la c*n comme ça . On a des composants, on les nomme, on les utilise. On aura aussi les composants anonymes et la récursivité (<this />) si le brouillon de ma spéc ne change pas (encore). On aurait moyen aussi d'avoir comme source de données une base SQL par exemple. J'imagine facilement un truc du genre :

<articles value="database://SELECT * FROM book" />

Pareil avec une lecture de fichier :

<articles value="xml://Foobar.xml?/books/book[type=article]" />

Ça ne reste que des suppositions, mais l'idée est celle-ci.

Ensuite on aurait la balise <overlap /> qui permettrait de modifier l'intérieur d'un composant à la volée. Par exemple :

<articles value="…">
  <overlap element="xpath expression">
    <!-- on remplace par autre chose -->
  </overlap>
</articles>

C'est l'idée, mais encore très brouillon.

J'ai encore d'autres trucs mais ça risque de changer pas mal, je ne veux pas tout bousculer .

Et enfin, j'ai parlé de XUL, le langage d'interface graphique de Mozilla, qui permet une interopérabilité de l'apparence et du comportement des éléments d'interface sur plusieurs plateformes. Ce sera pareil avec XYL qui aura un comportement adapté à chaque plateforme : gros écran, petit écran, téléphone etc. Et toujours en essayant de mettre en avant l'accessibilité et l'interopérabilité ainsi que les performances. Car XYL devrait gérer toutes les performances : HTTP, ccache etc.

Voilà l'idée .

Tu as bien compris le fonctionnement de XYL pour l'instant.
Oui pour SplObjectStorage, je pensais l'utiliser car mon système était un peu rudimendaire, quoi que très rapide. À tester sur d'énormes objets …
Oui j'ai corrigé le array_merge par array_merge_recursive, je l'ai vu après coup .
getData() retourne maintenant une référence, plus de copie donc.
Enfin, oui, Hoa_Xml_Element_Basic a une racine static, ce qui permet à tous les éléments — quelque soit leur profondeur — de retrouver leur racine avec selectRoot() .

Exact. C'est une erreur de ma part.
Le problème est qu'on ne peut ajouter d'attribut à une classe qui étend SimpleXMLElement. J'ai pensé au static mais j'ai réfléchis trop vite … Honte sur moi. Je vais changer ça.

Merci !

Hey ,

Le array_merge va peut-être casser les références. Si c'est le cas, je me ferai mon propre merge pour ne pas casser les array pointers et les références. Sachant que les array pointers se mettent en place lors du rendu, et le traitement des données (le liage des données) se sera déjà fait en amont.
En fait, tu donnes des données, tu en ajoutes etc. XYL va faire un premier passage pour voir si des composants veulent modifier/ajouter/supprimer des données. Deuxième passage : le liage des données. Enfin, troisième et dernier passage : le rendu.
Je vais tenter de confondre le premier et le second passage en un seul (merci la récursivité). Ça va être une technique un peu particulière, mais ça s'utilise souvent dans le parcours d'arbre recouvrant de poids minimal. Je ne vais pas m'étaler, les algos sont en ligne j'imagine.

Donc je pense qu'il n'y aura pas de problèmes avec les array pointers, sauf si on les utilise depuis l'extérieur. Va falloir protéger ça.

Je n'ai pas compris quand tu parles de modifier XYL. Je ne touche pas à XYL. On donne un ou plusieurs fichiers, on travaille dessus. Il n'y a pas de modification dynamique de XYL justement, c'est là tout l'enjeu. Quand on a plusieurs données … exemple : pour mon dernier exemple en date, une liste avec plusieurs <li>, on ne créé pas plusieurs éléments <li>, on en a qu'un seul, mais il va consommer une pile de données. Tant qu'il peut consommer, il se paint(). Pas d'opération DOM, c'est là tout l'enjeu. C'est donc beaucoup plus rapide !

Ah, attends, tu parles du store. Bah ma réponse reste la même. On ne touche pas XYL, donc pas le store. Store que je pense d'ailleurs faire remonter dans Hoa_Xml. Et spl_hash_object et SplObjectStorage me donne des résultats étranges. Je vais continuer à explorer mais je pense avoir trouver des comportements étranges (je n'irai pas jusqu'à dire bug).

Je n'utilise plus les foreach, trop d'effet de bords non désirés. En temps normal, ça ne me dérange pas, mais comme je récupère les array pointers à plusieurs endroits, dont hors de l'itération, c'est gênant …

L'écriture des données sera facilité. Pour l'instant j'ai écris les données en brut mais tu verras que je vais les transformer à la volée pour faciliter les entrées.
J'ai choisi les array parce que c'est natif à PHP. Si on a énormément de données, je ne veux pas perdre de temps à le transformer en StdClass, Hoa_StdClass, en Hoa_Tree, en Hoa_Graph ou je ne sais quoi. Ça fonctionne bien comme ça, c'est natif, c'est rapide.

L'idée c'est de faire une bibliothèque aussi, donc avec le moins de dépendances possibles pour pouvoir être réutilisée à part dans un autre projet. Uè, les problématiques sont pas toujours simples .

J'ai pensé à faire un xpath sur des array. Ce sera fait. Regarde la valeur des attributs value : value="?main", mais imagine value="?main/foo/", ce serait possible à la fin du projet. Surtout qu'on aura aussi value="database://…" ou ce genre de chose. Les données pourront venir d'un peu partout. Ça va être marrant à gérer .

J'aurai plutôt pensé conserver les funcs de merge natives mais reporter au dernier moment le mécanisme de liaison. En fait, déclencher cette étape  uniquement lors d'un rendu (et si rien n'a changé depuis un précédent rendu). C'est probablement ce à quoi tu as pensé.
Ceci + les array pointers qu'il faut contrôler finement devra être pris en compte pour l'api utilisateur. Cela fait un certain nombre d'états à maintenir. Si le souhait est que les choses se fassent de manière optimale, l'interface utilisateur devra être "blindée"

Oui, je vois où tu veux en venir. Je me plaçais dans le cas d'un utilisateur souhaitant générer (ou modifier) dynamiquement un doc XYL.

Oui pour les arrays natifs. La contre partie sera d'implémenter les mécanismes de selections et modifications. Et pour le coup, est-ce ça sera au final plus performant (et plus simple, mieux quoi) que SimpleXML par exemple.