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 !

Simian, aka Similarity Analyser est un outil des plus merveilleux. Il analysera vos lignes de code et détectera des potentielles répétitions.

A cela, nous couplons un gem de Jean-Michel Garnier (qui était présent au RubyCamp Lyonnais), Don’t Repeat Yourself.
Et à partir de maintenant, nous pouvons tester que nos applications Ruby et Rails sont DRY !!
J’ai testé et ça fonctionne plutôt du tonnerre.

Installation du plugin :
Si vous n’avez pas encore le catalogue de gems de GitHub, ajoutez-le :
gem sources -a http://gems.github.com
Puis installez le gem.
gem install dmathieu-dont_repeat_yourself
Vous constaterez que je vous fait installer non pas la version de Jean-Michel, mais la mienne. Les explications viennent plus bas.

Une fois que cela est fait, vous pouvez utiliser le plugin de trois manières possibles.

Dans vos tests

Avec Test::Unit

Créez le test suivant :
test "we don't repeat ourself" do
  assert_dry(rails_application.with_netbeans_reporting)
end

Avec RSpec

Créez le test suivant :
describe "Dupplicate lines Report: Don't Repeat Yourself" do
  it { ruby_project(File.dirname(__FILE__) + '/../').
    with_threshold_of_duplicate_lines(4).
    with_netbeans_reporting.
    should follow_the_dry_principle }
end

En ligne de commande

Tapez la commande suivante
dry-report

Ces rapports DRY sont même encapsulables dans Netbeans ou Textmate. Mais je n’ai pas encore penché mon nez là-dedans. Donc je vous laisse regarder ;)

Vous constaterez par ailleurs que je vous invite à installer le fork que j’ai fait du gem et non pas la version originelle.
La raison à cela est que en Rails 2.3, Test::Unit deviens ActiveSupport::TestCase.
Cette modification n’a pas encore été appliquée au gem originel. Mais je suis persuadé que cela ne saurait tarder ;)

 
Fork me on GitHub