Hello,
Mais pour lire sa valeur si je fais :
echo dcForm->user_id;
ça ne marche pas, car ça me renvoie l'objet complet avec :
dcForm->__get('user_id');
J'ai donc rajouté à la classe dcField la fonction :
public function __toString() { return $this->value; }
qui renvoie la valeur du champs de la classe dcField ce qui donne :
echo dcForm->user_id = echo dcForm->__get('user_id') = echo
dcField->__toString()
Très bonne idée
Le problème se pose alors pour le test d'existence de sa valeur
avec
empty(), en effet :
if (!empty(dcForm->user_id)) {...}
J'opterais plutôt pour un test via isset(). D'autant que la méthode
magique __isset() existe bien. Ca me semble plus propre.
2) Avec l'ajout de dcField->__toString() je peux enfin lire
facilement
sa valeur pour toutes les fonctions de validation de formulaire mais
pour poursuivre le formulaire je suis obligé d'écrire un truc assez
bizarre :
$form->user_id = $form->user_id;
Etrange non?! En fait ici je passe ce qui provient de ma validation de
formulaire vers mon futur champs de formulaire ! Il faudrait voir si on
ne devrait pas remplir les valeur de champs d'après les information du
_POST ? Ou si je me plante quelque part!
Pas si étrange : un champ n'est défini que s'il a bien été véhiculé
dans la requête. La méthose setup() du form est censés renseigner tous
les champs qui vont bien. Enfin... si je me souviens bien :)
3) Dernière petite question, j'ai souvent quelques variables à
passer
aux templates, pour l'instant je le fait avec $_ctx->ma_var = 'plop';
mais faudra quand même qu'on vois ce qu'on partage et ce qu'on ne
partage pas vers les templates ? Perso j'en ai aucune idée :-)
A voir avec le temps, et les besoins qui émergeront naturellement :)
PS: J'ai presque fini mon test de passage de auth.php vers Twig,
et je
trouve le code php vachement plus lisible à la fin et pourtant ce n'est
qu'un brouillon, ça promet de belle chose.
Yep, c'est tout le charme de Twig quand tout est bien en place derrière :)
--
Bruno