HTML5 n'a pas de schéma de validation actuellement. Je te laisse lire le mémoire de Henri Sivonen sur comment vérifier la conformance d'un document HTML5 : http://hsivonen.iki.fi/thesis/html5-conformance-checker. C'est pratique si t'arrives pas à dormir le soir 
.
Le principe sera simple. On va considérer que certains éléments peuvent embarquer/contenir d'autres, ou pas. On a cette notion en HTML (et plus forte dans HTML5) : http://dev.w3.org/html5/spec/content-mo … of-content. Faudra mettre ce principe dans XYL. Sauf qu'avec SimpleXML, les textnodes n'existent pas … C'est pratique dans le cas où on a <em>hello</em>, mais si on a he<em>ll</em>o, c'est pas la même chose du tout …
Il faut que je réfléchisse aux systèmes de fragment et tout ça. Faut que je fasse des tests de performances. Là je vais conssacrer tout mon temps à mon mariage (J-8 quand même) mais ça tournera toujours en fond.
Il y a quelque chose d'important que j'ai oublié : les éléments ont leur rendu mais rien sur le comportement. Je veux dire, les éléments ne vont pas s'exécuter. Alors que pourtant, il devrait s'exécuter ! Certains éléments pourraient en influencer d'autres. Par exemple la balise <head> d'HTML devrait recevoir de nouveaux scripts au fur et à mesure que la page se déroule.
Je ne veux pas reconstruire 300 objets à chaque fois car ce sera 300 accès au disque dur maximum, et ça, ça te plombe grave les performances. Faut que je trouve un moyen de construire un arbre parallèle qui étend mon arbre existant. Une sorte d'arbre fantôme (j'aime bien l'idée).
Je dois faire ça car SimpleXML ne construit un arbre qu'avec une seule classe. Classe qui doit être ou doit étendre SimpleXMLElement.
Si j'utilisais mon propre analyseur, je pourrais assigner une classe à chaque balise. Mais analyser un fichier XML avec PHP, c'est lent (même si plus puissant). C'est comme ça que fonctionnait l'ancien Hoa_Xml. Je dois être 20 fois plus rapide maintenant …
Ok pour r8t. J'ai beaucoup lu le code source mais pas testé. Pas encore eu le temps.
Javascript me fait peur en ce moment. On l'a en client-side, en server-side avec NodeJS, et même en document-side maintenant avec r8t ! C'est vrai que c'est un bon langage et qu'on fait beaucoup d'effort pour l'améliorer. Si seulement il y avait cet engoument pour PHP …
En me relisant, j'ai trouvé une nouvelle façon de traiter un document XYL.
Premier parcours de l'arbre XML : on construit notre arbre fantôme XYL en même temps que l'on lie les données.
Deuxième parcours : on exécute notre arbre fantôme ; exécution qui va modifier son propre data bucket.
Troisième et dernier parcours : on fait le rendu.
Le problème de ce procéder, c'est qu'on fait 3 parcours de l'arbre. Si l'arbre est gros, ce sera long.
Solutions :
Premier parcours : on construit l'arbre fantôme et on lie les données.
Second et dernier parcours : on exécute l'arbre et on fait un rendu partiel.
Un rendu partiel ça implique que le rendu est éclaté en plusieurs parties et que chaque nœud est capable de repeindre une partie du rendu. Exemple : on a parcouru <head>, il a fait son rendu ; dans le <body> on trouve un élément qui veut ajouter un <script>, alors <head> va se repeindre partiellement (soit ajouter, soit modifier etc.).
De cette façon, on supprime un parcours. On aura la notion de repaint, peut-être lourde mais j'y tenais. Le repaint est un moyen d'éviter du parcours mais pose quelques problèmes. Le principal est qu'on doit travailler avec des tampons. Tampons qui ne seront pas envoyer sur la sortie tout de suite. Donc impression de ralentissement. (C'est comme Firefox et Chrome : Chrome envoie vite des petites parties sur la sortie donc impression de vitesse, et Firefox envoie des parties plus grosses ; en vrai, Firefox va plus vite mais on a l'impression de l'inverse !).
Ça reste une affaire de compromis.
Voilà mes pensées du jour. Merci cher journal. 30 juillet 2010 .
« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
) ?