nur-ture/src/schema/TODO.md

104 lines
3.9 KiB
Markdown

# nulib\schema
* rajouter l'attribut "size" pour spécifier la taille maximale des valeurs
* cela pourrait servir pour générer automatiquement des tables SQL
* ou pour modéliser un schéma FSV
* support `max_size`, qui diffère de `size` en ce qu'on ne spécifie qu'une
taille maximum. sinon, faire `size` à la place de `max_size` et `fixed_size`
à la plage de `size`
* support `allowed_values`
* valeurs composite/computed
* analyse / vérification de la valeur complète après calcul du résultat, si
tous les résultats sont bons
* calcul des valeurs composites/computed par une fonction avant/après l'analyse
globale si résultat ok
* fonction `getter_func`, `setter_func`, `deleter_func` pour les propriétés de type
computed
* tdate et tdatetime. qu'en est-il des autres classes (delay, etc.)
* `parse_format` pour spécifier le format d'analyse au lieu de l'auto-détecter
* `ScalarSchema::from_property()`
* pour le support des propriétés des objets, il faudrait pouvoir spécifier
comment instancier l'objet. je ne sais pas si ça doit se mettre au niveau du
type, du schéma, ou autre
~~~php
Schema::ns($schema, [
"rt" => ["?string", "required" => true],
"rtd" => ["?int", "required" => true, "default" => 42],
"ot" => ["?int"],
"otd" => ["?string", "default" => "hello"],
"ot2" => ["int"],
"" => ["assoc",
"class" => MyClass::class,
],
]);
# peut provisionner la classe suivante
class MyClass {
public ?string $rt;
public ?int $rtd = 42;
public ?int $ot = null;
public ?string $otd = "hello";
public int $ot2 = 0;
}
~~~
il y a potentiellement un problème d'oeuf et de poule si on se sert de ce
genre de définitions pour autogénérer la classe
* l'argument $format de AssocWrapper::format() est un tableau associatif
`[$key => $format]`
cela permet de spécifier des format spécifiques pour certains champs.
* cela signifie que la valeur de retour n'est pas string :-(
retourner string|array
* 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", soit un mode automatique
activé par un paramètre où une valeur `"val"` devient `"val"=>true` si la clé
"val" existe dans le schéma
-*- coding: utf-8 mode: markdown -*- vim:sw=4:sts=4:et:ai:si:sta:fenc=utf-8:noeol:binary