Hey ,

J'ai mis du temps à répondre à ton message, mais je suis assez occupé …

C'est vrai que XYL est avant tout déclaratif. J'ai intuité ce problème et j'avais mis une notion de contexte dans la spécification mais ce n'était pas clair. Tes remarques ont débloqué quelques points mais pas tous.

On pourrait imaginer quelque chose du genre :

<rule name="foo" from="bar" value="?baz">
  <parameter value="?gordon1" />
  <parameter value="?gordon2" />
</rule>

<!-- plus loin dans le code -->

<yield value="?freeman">
  <apply rule="foo">
    <if>

    </if>
    <else>

    </else>
  </apply>
  …
</yield>

J'ai pensé à ça, mais je ne suis pas encore sûr de moi.
On aurait une liste des règles. Chaque règle est en fait définie en PHP :

class Foo extends … {

    public function rule ( $parameter … ) {

        return (bool) …;
    }
}

Quand on donne un nom à la règle, c'est pour l'utiliser dans un élément XYL. Et son attribut @from précise quelle classe on utilise. On peut lui passer des paramètres à partir du data buckets (ou d'autre part). L'idée serait de pouvoir combiner plusieurs classes dans l'attribut @from :

<rule name="foo" from="A B C D">
  <parameters>
    <parameter />
  </parameters>
  …
</rule>

Mais ça ne permet pas des combinaisons logiques : (A ou B), (A et B) ou (C et D) etc. Donc ça reste imprécis. On peut toujours construire cette combination logique dans une classe PHP et l'utiliser directement. C'est plus rapide, plus puissant mais j'aimerais avoir la même expressivité en PHP qu'avec XYL.

Pour l'application de la règle, je trouve ça verbeux. Le <apply>, <if>, <else>, … j'aime pas, pas du tout. C'est là que ma spéc' s'arrêtait. Je n'avais pas trouvé de moyen efficace pour faire ça.

Une idée ?

Enfin, tu proposes de remplacer les tableaux par des éléments SimpleXML c'est ça ? Comme ça on aurait directement les expressions XPath dessus (et CSS Query Selector au passage si on utilise un Hoa_Xml_Element) ? Ce serait en interne … hmm, oui mais si le bonhomme utilise du JSON, faudrait le convertir vers du XML. C'est un peu chiant (on passe par le tableau forcément). Pas plus léger d'avoir un tableau tu crois ?

En fait, je me suis dit que si j'arrivais déjà à coder le liage des données et la balise <yield>, j'aurai une base très solide. Ensuite, ajouter des règles ou ce genre de chose, ce ne sont que des éléments et des traitements supplémentaires. Mais si ma base est solide et très facilement manipulable, ce serait déjà pas mal.
Toi tu parles de modifier un document XYL. Pourquoi ? On en aurait besoin ?

Une entité ou deux, ça ne gêne pas des masses.
Je voulais rester sur des structures simples que PHP saurait optimiser de lui-même en fait. Est-ce que tu penses que ça pourrait être gênant par la suite ?

Le but ne serait pas d'avoir un xpath dans les @value, mais un chemin vers une idée. Ce serait un chemin genre une arborescende d'un système de fichier tu vois : ?a/b/c/d. Peut-être le support de certains wildcards mais pas plus. Bien sûr, si la valeur commence par « ? », alors on fera ça. J'avais imaginé d'autres choses : database://, ! (pour du CSS), xpath://, json://, rdf://, yaml:// etc.

Tes idées sont intéressantes. J'aime bien.
Est-ce que tu vois quelque chose de bloquant dans le système actuellement ? Car si nos avis peuvent être divergeants sur la structure des data buckets, on est d'accord sur le reste me semble-t-il ?

Concernant le data/store, mon avis ne diverge pas nécessairement du tien. J'ai juste fait part de mes reflexions en me projetant dans la suite du development par rapport aux attentes et use cases que les simples utilisateurs seraient en droit d'attendre.

Il se peut fortement que ce qui est actuellement en gestation soit tout à fait suffisant.
A part peut-être les histoires de conditions/rules. Et là peut être que StringTemplate (voir les liens plus haut) et son désuet support des conditions sous leur formes la plus simple suffira à avoir un truc qui tienne la route pour la plupart des besoins. Je me place dans le cas souhaitable où, comme tu l'as suggéré, les @value seraient juste des "pathes".

J'ai ajouté un commentaire sur la page du bug pour spl_object_hash().
J'ai bien peur que cela soit compliqué. Je n'avais pas du tout pensé à ce problème initialement.
Dériver des classes standard (SimpleXMLElement, PDO etc) c'est toujours un peu risqué

Je ne sais pas si ton idée de tableau poserait des problèmes de mémoire. C'est clair que ça va consommer plus de mémoire que si on n'avait rien du tout, mais j'imagine que le prob principal sera plutôt de garantir qu'il n'y a pas d'oublis ou de double référençages etc. Une difficulté pour le code de la librairies en quelque sorte.
L'implémentation actuelle utilise aussi de la mémoire pour le map/array_search donc l'un dans l'autre ça devrait se valoir...
Il faudrait mesurer plus précisément. Je pense que ta priorité est les perfs d'abord et en second la mémoire.

Pour SimpleXML (le "bug"), ça ne me parait pas simple. L'api a une sémantique de valeur et non de référence au niveau des zvals (pour les structures de libxml en interne, c'est une autre histoire). SimpleXML ne semble pas du tout avoir été conçu pour storer les zvals qu'il expose par ailleurs sur demande au user. Pour que cela fonctionne à peu près comme attendu, il faudrait offrir au user des var liées par références à la var initialement créée lors d'un premier accès. Ca serait source d'ennuis (décidément!) pour les histoires de ref counting (une fois créée, son ref count serait toujours supérieur ou égal à 1) et de manipulations dans d'autres parties du code (php n'aime pas trop les vars liées par ref).

En fait je pense que c'est plutôt spl_object_hash qui est trop archaique pour ce cas bien particulier. La représentation "php" (le zval) ne suffit pas à identifier de manière unique la structure sous jacente, qui en l'occurence provient d'une lib tierce (libxml).

Pour XYL et les règles/contexts, franchement, je ne sais pas
Ma crainte (qui est somme toute modérée;) est que le doc XYL en lui-même devienne trop complexe. Le challenge serait quand même, je pense, que le truc soit plus simple de xslt et xul tant sur la forme que sur le fond (qui dit fond, dit perfs qui vont se dégrader).

Donc en fait, je n'apporte aucune solution ni idée
Est-ce que tu as envisagé de manière concrete le type d'utilisation "finale" de la part d'un simple user? De quoi a-t-il besoins pour faire ses docs (documents après rendus, html etc) ? Les rules/contexts sont peut être superflus. Seule la notion de "condition simple" (à la StringTemplate) suffit.

Dernière fois dit par metagoto (28 Jul. 2010 15:00)