82 lines
3.4 KiB
Markdown
82 lines
3.4 KiB
Markdown
# nur\sery\schema
|
|
|
|
* implémenter support `analyzer_func`, `extractor_func`, `parser_func`,
|
|
`normalizer_func`, `formatter_func`
|
|
* dans AssocSchema, support `[key_prefix]` qui permet de spécifier un préfixe
|
|
commun aux champs dans le tableau destination, e.g
|
|
~~~php
|
|
$value = Schema::ns($schema, [
|
|
"a" => "?string",
|
|
"b" => "?int",
|
|
])->newValue();
|
|
$dest = ["x_a" => 5, "x_b" => "10"],
|
|
$value->reset($dest, null, [
|
|
"key_prefix" => "x_",
|
|
]);
|
|
# $dest vaut ["x_a" => "5", "x_b" => 10];
|
|
~~~
|
|
définir si le préfixe doit être spécifié sur le schéma ou sur la valeur...
|
|
actuellement, le code ne permet pas de définir de tels paramètres...
|
|
|
|
alternative: c'est lors de la *définition* du schéma que le préfixe est ajouté
|
|
e.g
|
|
~~~php
|
|
$value = Schema::ns($schema, [
|
|
"a" => "?string",
|
|
"b" => "?int",
|
|
], [
|
|
"key_prefix" => "x_",
|
|
])->newValue();
|
|
$dest = ["x_a" => 5, "x_b" => "10"],
|
|
$value->reset($dest);
|
|
# $dest vaut ["x_a" => "5", "x_b" => 10];
|
|
~~~
|
|
* dans la définition, `[type]` est remplacé par l'instance de IType lors de sa
|
|
résolution?
|
|
* implémenter l'instanciation de types avec des paramètres particuliers. *si*
|
|
des paramètres sont fournis, le type est instancié avec la signature
|
|
`IType($typeDefinition, $schemaDefinition)` e.g
|
|
~~~php
|
|
const SCHEMA = ["type", default, "required" => true];
|
|
# le type est instancié comme suit:
|
|
$type = new ttype();
|
|
|
|
const SCHEMA = [[["type", ...]], default, "required" => true];
|
|
# le type est instancié comme suit:
|
|
# le tableau peut être une liste ou associatif, c'est au type de décider ce
|
|
# qu'il en fait
|
|
$type = new ttype(["type", ...], SCHEMA);
|
|
~~~
|
|
* ajouter à IType les méthodes getName() pour le nom officiel du type,
|
|
getAliases() pour les alias supportés, et getClass() pour la définition de la
|
|
classe dans les méthodes et propriétés
|
|
getName() et getAliases() sont juste pour information, ils ne sont pas utilisés
|
|
lors de la résolution du type effectif.
|
|
* si cela a du sens, dans AssocSchema, n'instancier les schémas de chaque clé qu'à la demande.
|
|
l'idée est de ne pas perdre du temps à instancier un schéma qui ne serait pas utilisé
|
|
|
|
on pourrait avoir d'une manière générale quelque chose comme:
|
|
~~~
|
|
Schema::ensure(&$schema, ?array $def=null, $defKey=null): Schema;
|
|
~~~
|
|
* si $schema est une instance de Schema, la retourner
|
|
* si c'est un array, c'est une définition et il faut la remplacer par l'instance de Schema correspondant
|
|
* sinon, prendre $def comme définition
|
|
$key est la clé si $schema est dans un autre schema
|
|
* actuellement, pour un schéma associatif, si on normalise un tableau séquentiel,
|
|
chaque valeur correspond à la clé de même rang, eg. pour un schéma
|
|
~~~php
|
|
const SCHEMA = ["first" => DEF, "second" => DEF];
|
|
const ARRAY = ["first", "second"];
|
|
~~~
|
|
la valeur normalisée de `ARRAY` est `["first" => "first", "second" => "second"]`
|
|
|
|
cependant, dans certaines circonstances (notamment pour des paramètres), on
|
|
devrait pouvoir considérer une valeur indexée comme un flag, i.e la valeur
|
|
normalisée de ARRAY serait `["first" => true, "second" => true]`
|
|
|
|
la définition de ces "circonstances" est encore à faire: soit un paramètre
|
|
lors de la définition du schéma, soit un truc magique du genre "toutes les
|
|
valeurs séquentielles sont des clés du schéma"
|
|
|
|
-*- coding: utf-8 mode: markdown -*- vim:sw=4:sts=4:et:ai:si:sta:fenc=utf-8:noeol:binary |