Si vous avez déjà touché à Zend Framework, vous vous êtes peut-être déjà pris la tête sur ses formulaires.
Et dans ce cas la, vous comprenez déjà probablement ce que je veux dire avec ce titre. Sinon, la suite détaille.

Voici un exemple de formulaire un petit peu complexe.
Vous pouvez en voir le résultat sur la page de gestion des mots clés de RefStats.

Comme vous pouvez le constater, il est assez difficile de comprendre l’intérêt d’un tel formulaire, ce qu’il affichera et même les champs qu’il contient.

Le problème des formulaires ZF est le même que dans beaucoup d’autres composants du framework : ils veulent trop en faire.
Le but d’un formulaire côté serveur est pourtant simple : faciliter la validation des données.
Que cela soit dans Rails ou ceux-ci sont directement inclus dans les modèles ou dans Django et Symfony ou ceux-ci ne servent que à faire la validation, à chaque fois, les formulaires ne génèrent pas d’HTML automatiquement.

C’est, malheureusement, ce qu’essaye de faire Zend Framework.
Mais cela rends la chose illisible car pas ergonomique; impossible à modifier pour la première raison.
Et surtout, absolument pas DRY. Si vous avez besoin de placer deux fois le même formulaire pour les mêmes données. Mais les afficher différemment ou simplement ne pas permettre la modification de certaines données, il vous faut créer deux formulaires différents !
Alors qu’il serait tellement plus simple de ne faire qu’un seul formulaire mais deux pages HTML affichant celui-ci.

Du coup comme vous l’avez deviné, je ne vous conseille absolument pas d’utiliser ces formulaires.
Après, au niveau alternatives, je vous épargnerai Rails et Django. Tout autant que Symfony, qui requiert l’inclusion complète du framework.
En revanche Loic me souffle sur Twitter que JForms serait pas mal.
Mais il est l’un des développeurs du framework et je n’ai pas eu l’occasion de tester la chose. Donc vous êtes sans filet !

You probably already know (otherwise, I highly invite you to read the Ruby on Rails bases) how easy it is to validate datas with our favorite framework :)

if myDatas.save
#The datas have been saved
else
#There's an error. The myDatas.errors contains it.
end

After that, you only need to add some validation parameters for the datas in the model.
But now, let’s guess others validations cases, a bit particular that doesn’t enter in the « normal » case.

You only need to create a new method which will come validate your datas (the example above is completely fake) :

def validates_roxitude(*attribute)
reg = Regexp.new '/^ruby(.*?)rox$/'
self.errors.add('rox', 'Hey, Ruby rox. You have to say it !') unless reg.match attribute
end

Here, we declare an error except if the field starts par « ruby » and ends by « rox ».

We only need to force the validation with this method for our field and Ruby rox ! ;)
class myModel < ActiveRecord::Base
validates_roxitude :myField
end

Vous le savez probablement déjà (sinon, je ne peux que vous conseiller de voir les bases de Ruby on Rails) comment il est facile de valider des données avec notre framework préféré :)

if mesDonnees.save
#Les données ont bien été sauvegardées
else
# Il y a une erreur. mesDonnees.errors la contient il n'y a plus qu'à l'afficher.
end

Après, il n’y a plus qu’à ajouter des paramètres de validation des données dans le modèle.
Mais maintenant, supposons d’autres cas de validation un peu particuliers, qui ne rentrent pas dans le cas « normal ».

Vous n’avez qu’à créer une nouvelle méthode qui valide vos données (l’exemple ci-dessous est totalement bidon) :

def validates_roxitude(*attribut)
reg = Regexp.new '/^ruby(.*?)rox$/'
self.errors.add('rox', 'Hey, Ruby ça rox. Faut le dire !') unless reg.match attribut
end

Ici, nous mettons donc une erreur sauf si le champ « monChamp » commence par ruby et se termine par rox.

Il n’y a plus qu’à forcer la validation avec cette méthode et le tour est joué !
class monModel < ActiveRecord::Base
validates_roxitude :monChamp
end

 
Fork me on GitHub