Boire ou coder ... Pourquoi choisir?
Publié le 27 janvier 2009 23:00

Rails 2.3 : modèles de formulaires imbriqués

Supposons que vous ayez le cas suivant dans votre application : Vous affichez, sur une page, un ou plusieurs projets. Et pour chacun de ces projets, vous avez une ou plusieurs tâches. Vous désirez donc afficher, sur le formulaire de modification d'un projet, des input modifiables et une case à cocher "supprimer" pour chacune de ces tâches.

Vous allez donc placer le code suivant dans votre vue. Et, afin d'effectuer la manipulation appropriée à chaque fois, le second fichier du gist donné précédemment.

On a vu mieux niveau propreté du code que de placer ce genre de chose dans chacun des modèles utilisant des formulaires imbriqués. Et si en prime vous commencez à avoir, pour chaque projet, plusieurs membres, plusieurs catégories et plusieurs options, on est très mal barré.

C'est pourquoi Rails 2.3 implémentera un début de réflexion, qui devrait cependant continuer à évoluer dans les versions suivantes permettant de gérer ceci. Vous devrez donc d'abord commencer par réecrire votre vue.

<% form_for @project do |project_form| %>
    <div>
        <%= project_form.label :name, 'Project name:' %>
        <%= project_form.text_field :name %>
    </div>
    <% project_form.fields_for :tasks do |task_form| %>
        <p>
            <div>
                <%= task_form.label :name, 'Task:' %>
                <%= task_form.text_field :name %>
            </div></p>

<p>            <% unless task_form.object.new_record? %>
                <div>
                    <%= task_form.label :_delete, 'Remove:' %>
                    <%= task_form.check_box :_delete %>
                </div>
            <% end %>
        </p>
    <% end %>
    <%= project_form.submit %>
<% end %>

Puis votre modèle. Et la, c'est cool, j'ai même pas besoin de faire un document externe tellement c'est simple et clair :)

class Project < ActiveRecord::Base
    has_many :tasks
    accept_nested_attributes_for :tasks, :allow_destroy => true
end

Au niveau des validations, a l'heure actuelle (et c'est ce qui va probablement évoluer), lorsqu'une tâche n'est pas validée, l'erreur est reportée sur le projet. Pas facile donc de savoir quelle tâche vient d'échouer et donc de résoudre le problème facilement. C'est pourquoi la chose va devoir évoluer dans les versions suivantes.

Quoi qu'il en soit, cette nouvelle fonctionnalité, qui apparaitra dans Rails 2.3 me semble particulièrement cool pour être soulignée. Cet article est fortement inspiré de l'article Nested Model Forms du blog rubyonrails.org, qui explique également comment implémenter cette fonctionnalité dans votre application Rails dès aujourd'hui.

Chose que je vous déconseille cependant. Intégrer le composant d'une version qui n'est même pas encore en alpha n'est jamais une bonne idée :)

Commentaires

JB
JB dit: 27 janvier 2009 23:00

Je pense que ton premier lien est erronné (les deux premiers liens arrivent au même endroit).

Sinon très intéressant, merci pour le cours accéléré ;-)

Damien
Damien dit: 27 janvier 2009 23:00 Site web

C'est normal que les deux liens pointent vers le même endroit. Il y a deux documents dedans. Chaque lien doit pointer vers l'un des deux (mais gist ne propose pas d'ancre pour chaque document).

shorK
shorK dit: 20 octobre 2009 22:00

Bonjour,

vous dites : "Chose que je vous déconseille cependant. Intégrer le composant d’une version qui n’est même pas encore en alpha n’est jamais une bonne idée :)"

Est ce que c'est toujours le cas aujourd'hui ?

Damien
Damien dit: 20 octobre 2009 22:00 Site web

Oui. Rails 2.3.4 est la version stable à l'heure actuelle. http://weblog.rubyonrails.org/2009/9/4/ruby-on-rails-2-3-4

Postez un commentaire

Markdown activé