par
naholyr » 18 févr. 2009, 12:26
sfForm est une vraie plaie pour les usages quotidiens : petits formulaires souvent très personnalisés. Parce que même si ce n'est pas forcément compliqué de définir un nouveau widget ça fait tout de même beaucoup de code. Un formulaire avec 2 widgets custom (genre une select-box avec un peu de JS spécifique, et une checkbox à 3 états) et un bouton submit ça fait quand même 3 classes à écrire, voire 5 si on fait des "renderer" spécifiques, voir 7 si on ajoute les "validator"... Autant d'objets à instancier pour un petit formulaire, des fois ça donne un sentiment de lourdeur atroce
En revanche avec les PropelForms là on gagne en puissance de manière assez remarquable, et le nouvel admin-generator en profite au passage. C'est assez savoureux quand on écrit l'action d'inscription, pour un petit aperçu voici l'action (c'est pas un copier-coller mais un aperçu de ce à quoi ça ressemble) :
$this->form = new sfGuardUserForm();
$data = $request->getParameter('user');
$this->form->bindValues($data);
if ($this->form->isValid()) {
$this->form->save();
}
et le template :
<form action="sfGuardAuth/register" method="post">
<ul>
<?php echo $form->renderUsing('list') ?>
<li><input type="submit" /></li>
</ul>
</form>
La classe du formulaire en elle-même n'a pas eu à être écrite parce qu'elle l'est dans le plugin, mais globalement de toute façon elle hérite d'un PropelForm auto-généré avec le reste du modèle, et se contente de se fusionner avec un autre formulaire (pour la liaison utilisateur <-> profil). Et d'ailleurs au passage ce "sfForm::mergeForm()" est une petite merveille
Bref du bon du moins bon, mais ça apporte une puissance d'extensibilité similaire à ce qu'on a avec les classes "Configuration" apparues dans la 1.1.
Mais on s'éloigne vachement du sujet, et je n'ai hélas toujours pas la possibilité de faire mes tests pour te répondre à ton problème initial x]
sfForm est une vraie plaie pour les usages quotidiens : petits formulaires souvent très personnalisés. Parce que même si ce n'est pas forcément compliqué de définir un nouveau widget ça fait tout de même beaucoup de code. Un formulaire avec 2 widgets custom (genre une select-box avec un peu de JS spécifique, et une checkbox à 3 états) et un bouton submit ça fait quand même 3 classes à écrire, voire 5 si on fait des "renderer" spécifiques, voir 7 si on ajoute les "validator"... Autant d'objets à instancier pour un petit formulaire, des fois ça donne un sentiment de lourdeur atroce :)
En revanche avec les PropelForms là on gagne en puissance de manière assez remarquable, et le nouvel admin-generator en profite au passage. C'est assez savoureux quand on écrit l'action d'inscription, pour un petit aperçu voici l'action (c'est pas un copier-coller mais un aperçu de ce à quoi ça ressemble) :
[php]
$this->form = new sfGuardUserForm();
$data = $request->getParameter('user');
$this->form->bindValues($data);
if ($this->form->isValid()) {
$this->form->save();
}
[/php]
et le template :
[php]<form action="sfGuardAuth/register" method="post">
<ul>
<?php echo $form->renderUsing('list') ?>
<li><input type="submit" /></li>
</ul>
</form>[/php]
La classe du formulaire en elle-même n'a pas eu à être écrite parce qu'elle l'est dans le plugin, mais globalement de toute façon elle hérite d'un PropelForm auto-généré avec le reste du modèle, et se contente de se fusionner avec un autre formulaire (pour la liaison utilisateur <-> profil). Et d'ailleurs au passage ce "sfForm::mergeForm()" est une petite merveille ;)
Bref du bon du moins bon, mais ça apporte une puissance d'extensibilité similaire à ce qu'on a avec les classes "Configuration" apparues dans la 1.1.
Mais on s'éloigne vachement du sujet, et je n'ai hélas toujours pas la possibilité de faire mes tests pour te répondre à ton problème initial x]
