j'ai essayé de simplifier le code de la balise #CONFIG du plugin cfg, en
partant de l'idée qu'il y a fondamentalement deux modes de lecture : une,
sérialisée, pour le squelette, et une désérialisée pour les fonctions
"normales". J'ai l'impression que tout fonctionne comme avant, mais les
tests ne répondant pas "OK" j'ai du mal à en être sûr
Le seul truc qui a sauté, c'est le filtre |extrait que j'ai fait dégager
car il ne collait plus avec ce modèle. Sans doute pas dur à remettre si
besoin est, mais j'avoue que j'ai un doute sur son usage..
j'ai essayé de simplifier le code de la balise #CONFIG du plugin cfg,
bof
en
partant de l'idée qu'il y a fondamentalement deux modes de lecture : une,
sérialisée, pour le squelette, et une désérialisée pour les fonctions
"normales".
Squelettes ou php doivent obtenir le même résultat, je ne comprends pas.
Mon souci était surtout de renvoyer un résultat compatible avec le fonctionnement standard de #CONFIG, ce dont je ne suis pas du tout sur avec ta version.
J'ai l'impression que tout fonctionne comme avant, mais les
tests ne répondant pas "OK" j'ai du mal à en être sûr
Non, ça ne fonctionne pas comme avant puisque tu a viré le 2ème argument de lire_cfg() , la valeur défaut.
C'est important de conserver ça pour éviter des if() à chaque fois qu'on lit une config.
Le seul truc qui a sauté, c'est le filtre |extrait que j'ai fait dégager
car il ne collait plus avec ce modèle.
Je ne vois pas où "ca ne collait pas". L'idée était que vu que cette fonctionnalité de déserialize/extrait était nécessaire à cfg, autant la fournir dans un filtre commun. Il n'y avait pas de surcharge de code puisque finalement tout passait par là. L'intéret serait de pouvoir extraire non seulement de meta mais par exemple de toute table spécifique, session ...
J'oublie de précisez que si il y avait un "étage" lire_meta() dans la construction c'est qu'éventuellement il y aurait eu lire_session, lire_cookie ... séparer ce qui est stockage et ce qui est extraction.
j'ai essayé de simplifier le code de la balise #CONFIG du plugin cfg,
bof
bon bin tant pis, on peut revert
Ah j'ai vu les 300 commits qui suivent
Donc voilà, tout est remis à peu près d'aplomb, RIP le filtre extrait().
J'ai finalisé les tests, c'est sympa, tout est dans un petit tableau et ça teste à la fois lire_config() et #CONFIG sur la base de ce tableau. Oui, faut que je documente aussi rajouter 2 ou 3 tests, mais c'est facile maintenant.
Justement le test vérifie bien que dans le cas squelette, ie. par #CONFIG, on récupère toujours les tableaux sous forme sérialisée. Or, il semble que dans certains cas extremes, il peut etre intéressant de les récupérer brut de fonderie.
Ça voudrait dire qu'il faut utiliser éventuellement le 3ème argument $serialize dans #CONFIG{} ou est-ce que quelque chose comme #CONFIG*{} pourrait fonctionner ?
On fait comment pour les tests "squelette" alors ?
Je sais pas, là pour #CONFIG, je génère, à partir du tableau de cas de test, des squelettes dans local/cache-tests/ que je repasse ensuite à recuperer_fond()
Il y a un peu d'acrobatie nécessaire, mais ça fonctionne.
Chaque item de test dans ces squelettes possede un dt pour dire ce que c'est, un dd pour le résultat attendu et un dd pour la balise elle meme.
On verifie juste l'identité de ces 2 dd apres avoir exécuté le squelette.
Tout ça en blindant $GLOBALS['meta'] aux données de test , bien sûr.
Bon, c'est que des tests unitaires pour une balise , le sujet est bien plus vaste
--
toggg
