67 lines
2.4 KiB
Markdown
67 lines
2.4 KiB
Markdown
# nulib\schema
|
|
|
|
* tdate et tdatetime. qu'en est-il des autres classes (delay, etc.)
|
|
* possibilité de spécifier le format de la date à analyser
|
|
* ScalarSchema::from_property()
|
|
* possibilité de spécifier un type via sa classe, e.g
|
|
~~~php
|
|
Schema::ns($schema, [
|
|
MyType::class, null, "une valeur de type MyType"
|
|
]);
|
|
~~~
|
|
MyType doit implémenter IType
|
|
* type générique construit à partir d'un nom de classe, e.g
|
|
~~~php
|
|
Schema::ns($schema, [
|
|
MyClass::class, null, "une valeur de type MyClass"
|
|
]);
|
|
~~~
|
|
MyClass ne doit pas implémenter IType, et le type correspondant est créé avec
|
|
`new tgeneric(MyClass::class)`
|
|
|
|
* dans AssocSchema, support `[key_prefix]` qui permet de spécifier un préfixe
|
|
commun aux champs dans le tableau destination, e.g
|
|
~~~php
|
|
$wrapper = Schema::ns($schema, [
|
|
"a" => "?string",
|
|
"b" => "?int",
|
|
])->newWrapper();
|
|
$value = ["x_a" => 5, "x_b" => "10"],
|
|
$wrapper->reset($value, null, [
|
|
"key_prefix" => "x_",
|
|
]);
|
|
# $value 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
|
|
$wrapper = Schema::ns($schema, [
|
|
"a" => "?string",
|
|
"b" => "?int",
|
|
], [
|
|
"key_prefix" => "x_",
|
|
])->newWrapper();
|
|
$value = ["x_a" => 5, "x_b" => "10"],
|
|
$wrapper->reset($value);
|
|
# $value vaut ["x_a" => "5", "x_b" => 10];
|
|
~~~
|
|
* 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 |