ASCIIcasts - Full Episode Feed

Appareils mobiles

Wed, 10 Feb 2010 23:00:26 +0000

C'est devenu de plus en plus courant de naviguer sur des sites en utilisant des appareils mobiles, comme les smartphones. Comparés aux ordinateurs portables ou de bureau, ces machines ont de plus petits écrans et des fonctionalités plus limitées, et ayant cela en tête, il est important de vérifier vos applications web sur ces petits appareils pour voir comment ils réagissent.

La meilleur façon de le faire est de tester concrètement votre application sur un appareil. De toute évidence,“localhost” ne fonctionnera pas sur un mobile, et vous devrez donc utiliser soit l'adresse IP de votre machine sur laquelle tourne votre application soit sur votre domaine local, en présumant que le mobile soit aussi sur votre réseau local. Par exemple, la machine sur laquelle tourne l'application que l'on va utiliser dans cet épisode s'appelle noonoo, si bien que l'on va y avoir accès sur le réseau en tapant l'adresse http://noonoo.local:3000/.

Si vous ne pouvez pas y accéder physiquement, vous serez obligé de télécharger un simulateur pour l'appareil, pour lequel vous voulez tester votre application. Si vous voulez tester sur un iPhone, alors un simulateur est disponible sur le site d'Apple pour les développeurs. De la mêle manière, un émulateur fait partie du SDK Palm Pré.

Pour tester sur l'iPhone, une autre alternative est iPhoney. Il fournit presqu'exactement la même émulation qu'un iPhone, même s'il n'est pas aussi fidèle que le simulateur Apple, sauf qu'il n'est pas aussi lourd à télécharger que le SDK iPhone. Si vous avez prévu de tester un site qui devra avoir des comportements différents pour les mobiles, alors il ne faudra pas oublier de définir le user agent correctement dans le menu iPhoney, de telle sorte que le contenu approprié soit bien affiché.

Notre application tournant sur iPhoney.

L'apparence de l'application peut de tout évidence être améliorée pour l'affichage sur un mobile, et c'est que nous allons faire tout au long de cet épisode.

Commençons par ajouter une feuille de style (stylesheet) dans la layout de notre application, qui ne sera incluse que si notre application est visitée par un mobile.

/app/views/products/_fields.html.erb

  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  <html>
    <head>
      <title><%= h(yield(:title) || "Untitled") %></title>

      <%= stylesheet_link_tag 'application' %>
      <%= stylesheet_link_tag 'mobile' if mobile_device? %>
      <%= yield(:head) %>
    </head>

    <body>
    <!-- content omitted -->
    </body>
  </html>

La nouvelle feuille de style mobile ne sera incluse que si une méthode appelée mobile_device? retourne true, et pour cela nous allons écrire cette méthode. On aurait pu aussi utiliser l'attribut media de la balise link pour restreindre aux mobiles l'utilisation de cette feuille de style, mais les navigateurs mobiles pourraient interpréter cet attribut de façons fort différentes. En utilisant notre propre méthode pour déterminer s'il faut ou non inclure la feuille de style, on va avoir un meilleur contrôle sur quels appareils vont afficher cette feuille, lorsque l'on va lire la chaîne de leur user agent envoyé par leur navigateur.

La prochaine étape est d'écrire la méthode mobile_device?. on va la placer dans l'application controller, ainsi tous les controllers pourront avoir accès à cette méthode.

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  helper :all
  protect_from_forgery

  private
  def mobile_device?
    request.user_agent =~ /Mobile|webOS/
  end
  helper_method :mobile_device?
end

Dans cette méthode, on va vérifier la requête du user agent pour voir s'il contient soit le mot “Mobile”, correspondant aux appareils iPhone et Android, soit “webOS” correspondant au Palm Pré. Vous pouvez, bien sûr, customiser cette expression régulière pour cibler quels appareils doivent afficher la feuille de style mobile. Au final on désigne cette méthode comme une helper méthode, de telle sorte qu'on pourra y avoir accès dans toutes nos vues. Si vous décidez de cibler un appareil spécifique, il existe une liste complète d'agents pour appareils mobiles.

Maintenant que l'on a écrit notre helper méthode, on va écrire la feuille de style mobile, que les mobiles vont utiliser.

/public/stylesheets/mobile.css

body {
  background-color: #FFF;
}

#container {
  width: 90%;
  min-width: none;
  margin: 0 auto;
  background-color: #FFF;
  padding: 0;
  border: none;
  margin-top: 20px;
}

Afin de voir à quoi ressemble notre page avec notre feuille de style mobile, on peut utiliser les fonctions de simulation du user-agent dans Safari. (Safari propose un menu Développeur qui est, par défaut, désactivé. Pour l'activer, il faut se rendre dans les préférences du navigateur, menu Avancé et cocher la case correspondante; pour la version anglaise, Show Develop menu in menu bar.) (NdT: il existe aussi un module pour Firefox, appelé User Agent Switcher qui permet de changer dynamiquement son user agent, suivant différents profils.) Dans le menu Développeur > User Agent se trouve une liste de user-agents, qui peuvent être sélectionnés, incluant plusieurs des différentes versions de Safari Mobile. Si on choisit l'une d'elles et que l'on regarde de nouveau notre application, on va voir la page avec la feuille de style mobile qui lui est appliquée.

Basculer entre les Sites

Maintenant que nous avons notre helper méthode mobile_device?, on peut l'utiliser pour modifier le comportement du site en fonction de l'appareil qui le visite. Ce que l'on va ajouter, c'est un lien qui va permettre aux utilisateurs de basculer entre la version intégrale et la version mobile du site. Pour ce faire, on va modifier notre layout d'application en ajoutant le code suivant avant la balise body.

/app/views/layouts/application.html.erb

<p>
  <% if mobile_device? %>
    <%= link_to "Full Site", :mobile => 0 %>

  <% else %>
    <%= link_to "Mobile Site", :mobile => 1 %>
  <% end %>
</p>

Ce code va afficher un lien vers le site intégral si on est actuellement sur les pages mobiles et vice versa. Le lien va rediriger vers la page qui est actuellement visitée avec une chaîne de requête comme paramètre, appelée mobile, qui va déterminer quelle version du site à afficher.

Dans notre application controller, on peut définir un before_filter qui va définir une variable de session, si bien que, dès que le lien est cliqué, cette version continuera d'être affichée tout au long de la navigation de l'utilisateur sur le site. Le before_filter va définir une variable de session s'il y a un paramètre 'mobile' dans la chaîne de requête. On va aussi modifier notre méthode mobile_device? de telle sorte qu'elle vérifie si cette variable existe et, auquel cas, choisira quelle version du site à afficher, en se basant sur sa valeur. Si cette valeur n'a pas été définie, on se basera sur la chaîne de requête.

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  helper :all
  protect_from_forgery
  before_filter :prepare_for_mobile

  private
  def mobile_device?
    if session[:mobile_param]
      session[:mobile_param] == "1"
    else
      request.user_agent =~ /Mobile|webOS/
    end
  end
  helper_method :mobile_device?

  def prepare_for_mobile
    session[:mobile_param] = params[:mobile] if params[:mobile]
  end
end

Si on recharge la page maintenant, il va y avoir un lien vers la version intégrale du site, et lorsque l'on clique, on verra la version complète, même si on est en train de voir le site avec un user agent, dont la chaîne contient le mot “mobile”.

Cette préférence va demeurer, si bien que si l'on clique sur n'importe quel lien ci-dessus, on restera sur la version intégrale de l'application.

Vues distinctes pour les Appareils Mobiles

Tout ce que l'on a fait jusqu'à présent marchera pour les cas où l'on veut une application cousue-main pour des mobiles, mais qu'en serait-il si l'on a de plus grandes ambitions et que l'on veuille changer l'application afin qu'elle ressemble et réponde comme une application mobile native? Pour cela, il faudrait changer toutes les vues ou presque de notre application. Comment allons-nous faire?

L'astuce est de créer un nouveau type MIME dans notre application, et Rails fournit justement un fichier ad hoc pour cela: /config/initializers/mime_types.rb. Ce fichier contient un exemple commenté pour fournir un nouveau type iphone, que nous allons modifier pour créer notre nouveau type mobile. Cela nous permet d'avoir un nouveau format HTML alternatif pour les appareils mobiles.

/config/initializers/mime_types.rb

# Be sure to restart your server when you modify this file.

# Add new mime types for use in respond_to blocks:
# Mime::Type.register "text/richtext", :rtf
# Mime::Type.register_alias "text/html", :iphone
Mime::Type.register_alias "text/html", :mobile

De toute façon, on doit encore définir ce type MIME, et pour ce faire, on revient dans notre before_filter dans l'application controller et définir le format à :mobile si c'est la version mobile qui est demandée.

/app/controllers/application_controller.rb

def prepare_for_mobile
  session[:mobile_param] = params[:mobile] if params[:mobile]
  format :mobile if mobile_device?
end

Maintenant que le type MIME est défini, on peut l'utiliser dans nos actions des controllers pour changer le comportement de chaque action selon le type en utilisant respond_to, comme on va le démontrer dans l'action index du controller des projects.

/app/controllers/projects_controller.rb

def index
  @projects = Project.all
  respond_to do |format|
    format.html
    format.mobile
  end
end

Le bloc respond_to n'est pas nécessaire, si nous pouvons fournir une vue alternative basée sur le format. Dans ce cas, on a juste besoin de fournir a nouveau template ayant comme nom celui du nouveau format,là où normallement se trouve html. Pour la vue index ci-dessus, on va créer un fichier appelé /app/views/projects/index.mobile.erb et pour commencer, on y placer un peu de texte.

/app/views/projects/index.mobile.erb

  Voilà la version mobile!

Si on regarde la version mobile de cette page, on voit maintenant que la vue mobile s'affiche.

Maintenant que c'est en place, on peut créer une Interface Utilisateur (IU) qui va bien plus ressembler à une applicaion mobile native. Il existe un certain nombre de librairies qui permettent de rendre les choses plus faciles: iui et jQTouch et celle que nous allons utiliser ici est jQTouch. jQTouch facilite grandement les choses pour créer une appli web, qui ressemble à une appli iPhone.

Après avoir téléchargé et dézippé jQTouch, la structure des répertoires devrait être:

Pour faciliter l'utilisation de jQTouch, on va déplacer les répertoires extensions et themes dans le répertoire jqtouch et ensuite faire glisser ce répertoire dans le dossier public de notre application.

Ensuite, on va créer un nouveau fichier layout pour la version mobile de notre application.

/app/views/layouts/application.mobile.erb

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html>
  <head>
    <title><%= h(yield(:title) || "Untitled") %></title>
    <%= stylesheet_link_tag "/jqtouch/jqtouch.min.css", "/jqtouch/themes/apple/theme.min.css" %>

    <%= javascript_include_tag "/jqtouch/jquery.1.3.2.min.js", "/jqtouch/jqtouch.min.js", "mobile" %>
    <%= yield(:head) %>
  </head>
  <body>

    <div class="current">
      <%- if show_title? -%>
      <div class="toolbar">
        <%= link_to "Back", nil, :class => "back" unless current_page? root_path %>

        <h1><%=h yield(:title) %></h1>
        <%= yield(:toolbar) %>
      </div>
      <%- end -%>

      <% unless flash.empty? %>

        <div class="info">
        <%- flash.each do |name, msg| -%>
          <%= content_tag :div, msg, :id => "flash_#{name}" %>
        <%- end -%>

        </div>
      <% end %>

      <%= yield %>
    </div>
  </body>
</html>

Dans ce fichier layout, on va inclure quelques fichiers CSS, fournis par jQTouch et dans le même temps les références JavaScript de jQuery et de jQTouch. On va y mettre aussi une référence au fichier mobile.js, que l'on va créer. Dans cette layout, le contenu de la page est englobé dans une balise div ayant comme classe current. si cette page doit afficher un titre, alors il sera englobé dans une autre div de classe toolbar. Pareillement, si on doit afficher un méssage flash, il sera placé dans une autre div, cette fois avec une classe info. Enfin, on retourne yield de ce qui doit être affiché dans le template courant.

ensuite, il nous faut écrire le nouveau fichier mobile.js. Tout ce qu'on doit y mettre est un appel pour initaliser jQTouch.

/public/javascripts/mobile.js

$.jQTouch({});

La fonction d'initialisation prend un hash d'options, mais ici, on ne va définir aucun d'eux. Quand on va recharger de nouveau la page mobile des projets, on peut voir que les styles jQTouch sont bien appliqués, mais le rendu est assez moche, et aussi on n'y voit aucun contenu.

Si on revient au code de la vue mobile de la page, on peut remplacer le code substituable par un code qui listerait tous les projets et un compteur du nombre de tâches pour chacun des projets, et enfin un lien pour créer un nouveau projet.

/app/views/projects/index.mobile.erb

<% title "Projects" %>

<ul>
  <% for project in @projects %>
  <li class="arrow">
    <%= link_to h(project.name), project %>
    <small class="counter"><%= project.tasks.size %></small>

  </li>
  <% end %>
</ul>
<ul><li class="arrow"><%= link_to "New Project", new_project_path %></li></ul>

Après avoir rechargé de nouveau la page, on va voir une belle interface qui ressemble beaucoup à une application mobile native.

Évidemment l'interface sera bien plus petite lorsqu'affichée sur un iPhone, mais cela fonctionnera de la même façon sur un navigateur d'ordinateur.

Chaque vue de notre application aura aussi besoin d'une version mobile. Cela repésente bien trop de code à vous présenter, mais vous pouvez télécharger les sources sur la page Github de Ryan Bates. Une fois que cela est fait, on a une application mobile complètment fonctionnelle, qui ressemble à une application mobile.

Alors que l'on a un bien meilleur rendu mobile de notre application, on a perdu la possibilité de basculer vers la version intégrale. On va rajouter un bouton sur le côté droit de la barre d'outils (toolbar) du haut pour réactiver cette fonctionalité.

La toolbar est definie dans la layout mobile, et lui ajouter de nouveaux contrôles est facile, dans le sens où les éléments de jQTouch sont definis par des balises HTML. On peut donc ajouter un nouveau bouton en créant un nouveau lien à l'intérieur de la div toolbar et en lui définissant une classe button.

/app/views/layouts/application.mobile.erb

<div class="toolbar">
  <%= link_to "Back", nil, :class => "back" unless current_page? root_path %>

  <h1><%=h yield(:title) %></h1>
  <%= link_to "Full Site", root_url(:mobile => 0), :class => "button", :rel => "external" %>

   <%= yield(:toolbar) %>
</div>

On doit aussi définir un attribut rel ayant une valeur d'external, ainsi jQTouch traitera ce lien comme un appel externe à un autre site. Si on ne fait pas cela, une requête AJAX sera faite, ce qui n'est pas exactement ce que l'on recherche.

Lorsqu'on recharge la page une dernière fois, on aura un bouton sur chaque page, qui pourra nous emmener sur la version intégrale du site.

Formulaire avec modèles imbriqués (2ème partie)

Tue, 09 Feb 2010 20:57:29 +0000

Dans l'épisode précédent, nous avions abordé comment créer un formulaire pouvant gérer plusieurs modèles imbriqués. Dans cette application, on avait créé pour cela un modèle Enquête Survey, pour lequel chaque Survey possède plusieurs Questions et chaque Question ayant elle-même plusieurs réponses Answers.

Dans les modèles Survey et Question, on a utilisé accepts_nested_attributes_for pour pouvoir créer, éditer et supprimer des enregistrements imbriqués à travers un seul modèle.

Actuellement dans notre application, si on veut supprimer une question ou une réponse, on doit utiliser un checkbox. Parallèlement, on n'a aucun autre moyen d'ajouter de nouvelles questions ou réponses au moyen du même formulaire. Dans cet épisode on se propose de régler ces problèmes par l'utilisation de JavaScript afin de modifier le formulaire existant au moyen de liens, pour créer et supprimer des modèles dynamiquement.

Le JavaScript que l'on va écrire implique quelques manipulations du DOM, aussi allons-nous utiliser Prototype pour nous simplifier la tâche. Pour ajouter Prototype à notre application, on va rajouter la ligne suivante dans la partie <head> de la layout de l'application.

/app/views/layouts/application.html.erb

<%= javascript_include_tag :defaults, :cache => true %>

Si vous préférez utiliser jQuery, c'est tout à fait possible et vous trouverez l'équivalent jQuery à la fin de cet épisode.

Ajout de liens pour supprimer des réponses

Commençons par la partie la plus facile: remplacer les checkbox, utilisés pour supprimer les questions et les réponses, par des liens. Tout d'abord, voyons le cas des réponses.

Le code responsable de l'affichage de chaque réponse se trouve dans le partial appelé answer_fields et ressemble à ceci:

/app/views/surveys/_answer_fields.html.erb

<p>
  <%= f.label :content, "Answer" %>

  <%= f.text_field :content %>
  <%= f.check_box :_destroy %>
  <%= f.label :_destroy, "Remove" %>
</p>

Dans le code ci-dessus, se trouve le checkbox _destroy, que nous voulons cocher pour supprimer la réponse. On va le remplacer par un champ caché, dont la valeur sera définie quand le lien “remove” sera cliqué. De cette façon, on pourra toujours indiquer quelle sera la réponse à supprimer.

On va remplacer le label du code ci-dessus par un lien et utiliser link_to_function pour créer un lien qui déclenchera un appel Javascript lorsqu'il sera cliqué. Avec le champ caché et le lien, le code du partial devrait ressembler à ceci:

/app/views/surveys/_answer_fields.html.erb

<p class="fields">
  <%= f.label :content, "Answer" %>

  <%= f.text_field :content %>
  <%= f.hidden_field :_destroy %>
  <%= link_to_function "remove", "remove_fields(this)" %>
</p>

Quand le lien “remove” à côté d'une réponse est cliqué, cela va déclencher un appel à une fonction JavaScript, appelée remove_fields, qui sera passée comme argument dans le lien, nous permettant ainsi d'utiliser comme élément de reference pour retrouver les autres éléments relatifs à cette réponse. Il n'y a pas de moyen direct d'avoir accès à tous ces champs, si bien que l'on va ajouter un nom de class au paragraphe englobant tous ces éléments, de telle sorte qu'on puisse les retrouver plus facilement.

Ensuite il nous faut écrire cette fonction remove_fields. On va le faire dans le fichier application.js, car c'est un fichier qui est automatiquement chargé dans nos pages, parce qu'on a spécifié la propriété JavaScript :defaults.

/public/javascripts/application.js

function remove_fields(link) {
	$(link).previous("input[type=hidden]").value = "1";
	$(link).up(".fields").hide();
}

Cette fonction effectue deux actions. La première utilise la fonction Prototype previous pour trouver le premier champ caché relatif au lien qui l'a appelé, le champ _destroy, et lui assigne sa valeur à 1, de telle sorte que la réponse sera marquée comme étant à supprimer. Elle utilise ensuite up pour remonter l'arbre du DOM à partir du lien, jusqu'à ce qu'elle retrouve un élément de la classe fields, qui est le nom de la classe que nous avons donné au paragraphe, englobant les champs réponses, et qui le masque aussi lorsque la réponse est cachée.

Si maintenant on recharge la page enquête, on verra apparaître un lien en face de chaque réponse.

Si on clique sur quelques liens, la valeur du champ caché _destroy sera mise à 1 pour toutes ces réponses comme étant à supprimer et leurs champs dans le formulaire seront cachés.

Notez bien que l'on n'utilise pas AJAX pour renvoyer les valeurs mises à jour du formulaire, lorsque l'on clique sur le lien et bien que l'on masque immédiatement les réponses supprimées, rien ne sera mis à jour dans la base de données tant que le formulaire n'aura pas été envoyé. Lorsqu'on envoie le formulaire, les réponses seront supprimées et on verra le résultat apparaître sur la show de l'enquête.

Suppression des Questions

A présent que l'on peut supprimer des réponses via des liens, on va s'intéresser au cas des questions. La manière de supprimer une question est fondamentalement la même que celle pour une réponse, on va pouvoir réutiliser une partie du code que l'on avait écrit un peu plus tôt.

Comme on l'a fait pour les réponses, on va remplacer le checkbox et le label par un champ caché et on va reprendre cette partie du code du partial answer_fields et on va le placer dans une nouvelle helper méthode appelée link_to_remove_fields, en lui passant dans le lien, le texte qu'on veut lui voire apparaître et la variable form f.

/app/views/surveys/_answer_fields.html.erb

<p class="fields">
  <%= f.label :content, "Answer" %>
  <%= f.text_field :content %>
  <%= link_to_remove_fields "remove", f %>

</p>

On va maintenant écrire cette méthode dans le fichier application_helper.

/app/helpers/application_helper.rb

# Methods added to this helper will be available to all templates in the application.
module ApplicationHelper
  def link_to_remove_fields(name, f)
    f.hidden_field(:_destroy) + link_to_function(name, "remove_fields(this)")
  end
end

Les méthodes qui créent des champs de formulaire retournent des chaînes de caractères (strings), si bien que l'on peut concatenater le HTML généré par les méthodes f.hidden_field et link_to_functionet les retourner dans le partial.

On pourra aussi utiliser notre méthode dans le partial question_fields.

/app/views/surveys/_question_fields.html.erb

<div class="fields">
  <p>
    <%= f.label :content, "Question" %>
    <%= link_to_remove_fields "remove", f%><br />

    <%= f.text_area :content, :rows => 3 %><br />
  </p>
  <% f.fields_for :answers do |builder| %>
    <%= render 'answer_fields', :f => builder %>

  <% end %>
</div>

Comme notre fonction JavaScript remove_fields recherche un élément de la classe fields lorsque l'on masque une question ou une réponse, on a englobé tout le partial dans un élément div avec ce même nom de classe, de telle sorte que lorsqu'on clique sur un lien “remove” pour une question, cette question sera masquée en même temps que ses réponses.

Si maintenant, on regarde la page edit d'une enquête et que l'on clique sur le lien “remove” d'une question, celle-ci va être supprimée en même temps que ses réponses qui l'accompagnent, et quand on envoie le formulaire, la question et toutes ses réponses seront supprimées de l'enquête.

Ajout de Questions et Réponses

Et maintenant, la partie la plus délicate: ajouter de nouvelles questions and réponses. On veut des liens sur le formulaire qui créeront les nouveaux champs dynamiquement lorsqu'on cliquera dessus. Ce qui rend ceci difficile est que le JavaScript aura besoin d'avoir accès à un ensemble de champs vides pour que l'on puisse créer une nouvelle question ou réponse, lorsque le lien est cliqué.

Pour ce faire, on va écrire une nouvelle méthode dans l'application helper, appelée link_to_add_fields. On pourra utiliser cette méthode dès lors que l'on a besoin d'afficher un lien pour ajouter les champs d'une nouvelle question, ou réponse, sur le formulaire. Le code de cette méthode ressemblera à ceci:

/app/helpers/application_helper.rb

def link_to_add_fields(name, f, association)
  new_object = f.object.class.reflect_on_association(association).klass.new
  fields = f.fields_for(association, new_object, :child_index => "new_#{association}") do |builder|
    render(association.to_s.singularize + "_fields", :f => builder)
  end
  link_to_function(name, h("add_fields(this, \"#{association}\", \"#{escape_javascript(fields)}\")"))
end

Cette méthode prend trois arguments: name, qui sera le texte du lien, f, l'objet form builder et l'association, qui dans ce cas sera soit “questions” soit “answers”.

La première ligne de cette méthode crée une nouvelle instance de la classe de cette nouvelle association, c-à-d une nouvelle Question ou Answer. Cela signifie que l'on a un objet template, qui va nous servir à créer les nouveaux champs du formulaire.

La seconde partie du code construit une chaîne avec les champs du formulaire de cet objet, de telle sorte que l'on peut les insérer dans la fonction javascript qui les ajoutera au formulaire quand le lien sera cliqué. Ceci est possible en appelant le partial approprié, passé par le form builder f. La seule chose vraiment nouvelle ici est :child_index. On a fait cela pour avoir une référence de la nouvelle question ou réponse lors de la création des champs. Dans le code JavaScript, on va remplacer ce nom par un identifiant unique basé sur l'heure courante. De cette façon, chaque fois que l'on va créer une question ou réponse, on aura un index unique, qui nous permettra de l'identifier lorsqu'on enverra le formulaire.

On va de nouveau utiliser la méthode link_to_function, lui passant le nom du lien etun appel à la fonction JavaScript appelée add_fields, à laquelle on lui passe le lien, le nom de l'association et une chaîne contenant le texte échappé des champs du formulaire.

Maintenant, revenons au JavaScript et écrivons la fonction add_fields.

/public/javascripts/application.js

function add_fields(link, association, content) {
  var new_id = new Date().getTime();
  var regexp = new RegExp("new_" + association, "g");
  $(link).up().insert({
	before: content.replace(regexp, new_id)
  });
}

Cette fonction prend les 3 arguments, dont on a parlé un peu plus tôt: le lien qui a été cliqué, le nom de l'association et une chaîne contenant le HTML des champs du formulaire. La première chose que cette fonction fait est de créer un nouvel id pour les éléments du formulaire. Si on crée plusieurs nouvelles questions ou réponses, on ne veut pas qu'ils aient tous le même index, sinon ils seraient considérés comme appartenant au même modèle lors de l'insertion. On va utiliser l'heure courante pour rendre l'id unique dans une expression régulière pour remplacer la chaîne “new_question” ou “new_answer” des champs du formulaire par ce nouvel identifiant unique. Ceci étant fait, on va insérer la chaîne des champs du formulaire à la bonne place dans le DOM.

Ceci marque la fin de la partie la plus délicate. Tout ce que l'on a à faire maintenant, c'est de rajouter les liens eux-mêmes. Dans le partial question_fields, on va rajouter un lien link_to_add_fields, qui permet d'ajouter une nouvelle réponse, en lui passant comme paramètre :answers comme de l'association ,car une question possède plusieurs réponses.

/app/views/surveys/_question_fields.html.erb

<div class="fields">

  <p>
    <%= f.label :content, "Question" %>
    <%= link_to_remove_fields "remove", f %><br />
    <%= f.text_area :content, :rows => 3 %><br />

  </p>
  <% f.fields_for :answers do |builder| %>
    <%= render 'answer_fields', :f => builder %>
  <% end %>
  <p><%= link_to_add_fields "Add Answer", f, :answers %></p>

</div>

On peut faire la même chose dans le formulaire enquête pour ajouter un lien “Add Question”.

/app/views/surveys/_form.html.erb

<% form_for @survey do |f| %>
  <%= f.error_messages %>

  <p>
    <%= f.label :name %><br />
    <%= f.text_field :name %>
  </p>
  <% f.fields_for :questions do |builder| %>
    <%= render 'question_fields', :f => builder %>

  <% end %>
  <p><%= link_to_add_fields "Add Question", f, :questions %>
  <p><%= f.submit "Submit" %></p>

<% end %>

Si on recharge la page enquête maintenant, on devrait voir les liens pour ajouter une nouvelle question ou réponse et lorsqu'on clique sur l'un d'eux, un nouveau champ va apparaître sur le formulaire.

Un champ réponse apparaît sur le formulaire, lorqu'on clique sur le lien “Add Answer”.

Si on remplit le nouveau champ réponse ci-dessus avec “jQuery” et que l'on soumet le formulaire, la nouvelle réponse sera ajoutée.

Nous avons atteint notre but et maintenant nous avons un formulaire, sur lesquel on peut dynamiquement ajouter ou supprimer des champs et avoir la base de données mise à jour de façon appropriée, lorsque le formulaire est envoyé.

Alternative utilisant jQuery

Le code JavaScript, que l'on a écrit dans cet épisode fonctionne avec Prototype. Si vous préférez utilier jQuery, le code devrait ressembler à ceci:

function remove_fields(link) {
	$(link).prev("input[type=hidden]").val("1");
	$(link).closest(".fields").hide();
}

function add_fields(link, association, content) {
	var new_id = new Date().getTime();
	var regexp = new RegExp("new_" + association, "g");
	$(link).parent().before(content.replace(regexp, new_id));
}

Ce code est très semblable au code pour Prototype, que l'on a pu écrire.

Certains d'entre vous seront peut-être choqués que le JavaScript que nous avons écrit manque un peu de discrétion. Bien qu'une solution discrète soit toujours préférable, il n'y en a pas vraiment pour notre problème, qui soit suffisamment simple à présenter dans cet épisode. Ryan Bates travaille actuellement sur un plugin appelé nested_form, utilisant jQuery et qui permettra de gérer des formulaires imbriqués de façon discrète. Ce plugin en est encore à un stade primitif, et s'il peut vous être utile, pensez à venir le visiter de temps à autre et à suivre ses évolutions.

Formulaire avec modèles imbriqués (1ère partie)

Wed, 27 Jan 2010 21:19:36 +0000

En 2007, une série d’épisodes couvrait la création de formulaires complexes, qui pouvaient gérer plusieurs modèles dans le même formulaire. Cette série est maintenant un peu dépassée et à présent, on va aborder des techniques plus modernes pour gérer des formulaires incluant plusieurs modèles.

Une des différences majeures dans l’approche de ce problème est la méthode accepts_nested_attributes_for, qui a été ajoutée à Rails 2.3. Nous allons l’utiliser tout au long de cette série, si bien qu’il vous faudra une version de Rails récente (>2.3) pour que vous puissiez utiliser cette technique dans votre propre application.

La documentation est intéressante à lire et montre bien comment l’utiliser avec des attributs imbriqués sur une simple mise à jour, mais cela devient moins évident lorsqu’il faut l’utiliser au niveau de la vue elle-même. C’est ce que nous allons voir.

Notre application ‘Survey’

Tout d’abord, l’objectif de cette application a pour but de gérer des enquêtes (surveys). Cette application comportera un formulaire (complexe) pour créer et modifier des enquêtes, nous permettant d’entrer un nom pour l’enquête, ainsi qu’un certain nombre de questions et chaque question pouvant avoir plusieurs réponses. Le formulaire comportera aussi des liens pour ajouter ou retirer dynamiquement des questions et des réponses à partir d’une même enquête.

Le formulaire pour créer et modifier les enquêtes.

Ce que nous avons ici est une association fortement imbriquée, dans laquelle une enquête a plusieurs questions, qui ont elles-mêmes plusieurs réponses. Dans les épisodes précédents sur les formulaires complexes, il n’était pas possible de créer des formulaires avec un tel type de relation, mais maintenant, depuis Rails 2.3, c’est possible.

Pour commencer

Nous allons démarrer de zéro cette application d’enquêtes et nous commencerons donc par créer une application Rails que nous appellerons: surveysays.

rails surveysays

Pour simplifer l’écriture, on utilisera 2 des générateurs de Ryan Bates et on commencera par nifty_layout pour générer un modèle de page (layout) pour toute l’application.

script/generate nifty_layout

Notre application comportera 3 modèles: Survey (Enquête), Question, Answer (Réponse). Commençons par les enquêtes et utilisons le générateur nifty_scaffold pour créer un scaffold. Survey aura un seul attribut, son nom (name).

script/generate nifty_scaffold survey name:string

Ensuite lançons la migration pour créer la table des enquêtes dans la base de données.

rake db:migrate

Si on regarde de plus près les fichiers générés par le scaffold, on peut à présent lister, créer et modifier les enquêtes à travers un formulaire basique sur lequel nous allons nous appuyer.

La première étape est de créer le modèle Question des questions. Il incluera un champ survey_id et un champ contenu (content) référent au texte de la question.

Ceci étant fait, migrons une nouvelle fois pour créer la table questions.

L’étape suivante est de créer la relation entre Survey et Question dans leur modèle respectif.

/app/models/question.rb

 
  class Question < ActiveRecord::Base
    belongs_to :survey
  end

/app/models/survey.rb

 
  class Survey < ActiveRecord::Base
    has_many :questions, :dependent => :destroy
  end

Notez que dans le modèle Survey nous avons utilisé :dependent => :destroy de telle sorte que si on supprime une enquête, les questions le seront aussi.

Dans le modèle Survey nous allons utiliser accepts_nested_attributes_for afin de gérer les questions à travers le modèle Survey. Ce faisant, nous pouvons créer, modifier ou détruire des questions lorsque nous mettons à jour un attribut d’une enquête.

/app/models/survey.rb

 
    class Survey < ActiveRecord::Base
      has_many :questions, :dependent => :destroy
      accepts_nested_attributes_for :questions
    end

Création du formulaire

Maintenant que les modèles Survey et Question sont bien établis, nous pouvons pousuivre avec le formulaire des enquêtes. Ce que nous voulons faire à présent, c’est d’ajouter dans les champs pour chaque question de l’enquête. Nous pouvons utiliser la méthodefields_for pour gérer les champs associés. Le générateur va rendre un label et une zone de texte pour chaque question.

/app/views/survey/_form.html.erb

 
  <% form_for @survey do |f| %>
    <%= f.error_messages %>
    <p>
      <%= f.label :name %><br />
      <%= f.text_field :name %>
    </p>
    <% f.fields_for :questions do |builder| %>
    <p>
      <%= builder.label :content, "Question" %><br />
      <%= builder.text_area :content, :rows => 3 %>
    </p>
    <% end %>
    <p><%= f.submit "Submit" %></p>
  <% end %>

Lorsque nous rechargeons le formulaire, il ressemble à ce qu’il était auparavant. Parce qu’une nouvelle enquête ne possède aucune question associée, cela n’affichera aucun champ question. Au final, nous voulons avoir un lien “Add Question” sur le formulaire, mais pour l’instant nous allons créer seulement quelques questions avec l’action new du SurveyController.

/app/controllers/surveys_controller.rb

 
  def new
    @survey = Survey.new
    3.times { @survey.questions.build }
  end

Ceci va générer 3 questions pour une nouvelle enquête, que nous voyons apparaître lorsque nous rechargeons la page. Remplissons maintenant le nom et les 2 premières questions puis souemttons la nouvelle enquête.

Lorsque nous soumettons l’enquête, un nouvel enregistrement Survey va être créé, mais nous ne pourrons voir ses questions , car elles ne sont pas affichées sur la page. Pour régler cela, on va modifier la vu de show pour Survey pour afficher les questions de l’enquête.

/app/views/survey/show.html.erb

 
  <% title "Survey" %>

  <p>
    <strong>Name:</strong>
    <%=h @survey.name %>
  </p>

  <ol>
    <% for question in @survey.questions %>
    <li><%= h question.content %></li>
    <% end %>
  </ol>

  <p>
    <%= link_to "Edit", edit_survey_path(@survey) %> |
    <%= link_to "Destroy", @survey, :confirm => ’Are you sure?’, :method => :delete %> |
    <%= link_to "View All", surveys_path %>
  </p>

Lorque nous rechargeons la page de l’enquête, nous allons voir les questions, ce qui prouve bien qu’une fois l’enquête enregistrée, les questions le sont bien aussi.

On peut aussi éditer une enquête et si on change n’importe quelle question, elles seront toutes mises à jour lorsque nous allons soumettre le formulaire.

Sur la page ci-dessus, trois questions s’affichent, même si on n’a rentré des valeurs que pour deux. Ce serait bien mieux si les questions vides pouvaient être automatiquement retirées. La méthode accepts_nested_attributes_for a une option reject_if que l’on va utiliser pour cela. Cette méthode accepte un lambda qui prend un hash d’attributs en paramètre et on va utiliser ce hash to rejeter une question si content est vide.

/app/models/survey.rb

 
  class Survey < ActiveRecord::Base
    has_many :questions, :dependent => :destroy
    accepts_nested_attributes_for :questions, :reject_if => lambda { |a| a[:content].blank? }
  end

Si on crée maintenant une nouvelle enquête avec seulement deux champs questions remplis, uniquement 2 questions seront créées et on ne verra pas de question vide s’afficher.

Comment faire si on veut supprimer des questions existantes lorsqu’on est en train de modifier une enquête? Dans l’application finale, on veut utiliser un lien pour supprimer les questions, mais pour l’instant nous allons au plus facile et simplement mettre un checkbox. Dans le partial _form, on ajoute un checkbox et un label qui va de pair.

/app/views/survey/_form.html.erb

 
  <% form_for @survey do |f| %>
    <%= f.error_messages %>
    <p>
      <%= f.label :name %><br />
      <%= f.text_field :name %>
    </p>
    <% f.fields_for :questions do |builder| %>
    <p>
      <%= builder.label :content, "Question" %><br />
      <%= builder.text_area :content, :rows => 3 %>
      <%= builder.check_box :_destroy %>
      <%= builder.label :_destroy, "Remove Question" %>
    </p>
    <% end %>
    <p><%= f.submit "Submit" %></p>
  <% end %>

L’astuce ici est dans le nom de l’attribut pour la checkbox: _destroy. Quand il a une valeur de true, c-a-d quand le checkbox est coché, L’enregistrement sera supprimé lorsque le formulaire sera soumis.

Afin que tout ceci fontionne, on doit l’activer à travers accepts_nested_attributes_for dans le modèle Survey en ajoutant :allow_destroy => true.

/apps/models/survey.rb

 
  class Survey < ActiveRecord::Base
    has_many :questions, :dependent => :destroy
    accepts_nested_attributes_for :questions, :reject_if => lambda { |a| a[:content].blank? }, :allow_destroy => true
  end

Lorqu’on recharge la page, on a à présent un checkbox “Remove Question” à côté de chaque question.

Si on coche le checkbox “Remove Question” en face d’une des questions et que l’on soumet le formulaire, cette question sera supprimée.

Ajout de questions

Les questions sont maintenant définies comme on voulait mais pas les réponses. On commence donc par créer le modèle Answer et son imbrication. Premièrement on va générer le modèle.

script/generate model answer question_id:integer content:string

Ensuite on migre de nouveau la base de données.

rake db:migrate

Puis on crée la relation entre Answer et Question. Answer définit belong_to Question.

/app/models/answer.rb

 
  class Answer < ActiveRecord::Base
    belongs_to :question
  end

Pour Question il va falloir utiliser accepts_nested_attributes_for de la même façon que cela avait été fait pour Survey.

/app/models/question.rb

  class Question < ActiveRecord::Base
    belongs_to :survey
    has_many :answers, :dependent => :destroy
    accepts_nested_attributes_for :answers, :reject_if => lambda { |a| a[:content].blank? }, :allow_destroy => true
  end

Dans le formulaire on aura besoin de champs pour les réponses, mais le code du form view va vite devenir fouilli si on lui rajoute un autre modèle imbriqué. Plus tard, on voudra ajouter des questions sur le formulaire via un lien avec du JavaScript, et pour ces deux raisons, on va placer le code responsable de chaque question dans un partial appelé question_fields.

Le form view devrait ressembler à cela.

/app/views/surveys/_form.html.erb

 
  <% form_for @survey do |f| %>
    <%= f.error_messages %>
    <p>
      <%= f.label :name %><br />
      <%= f.text_field :name %>
    </p>
    <% f.fields_for :questions do |builder| %>
      <%= render ’question_fields’, :f => builder %>
    <% end %>
    <p><%= f.submit "Submit" %></p>
  <% end %>

Notez qu’on lui passe juste le nom du partial en tant que string, c’est un raccourci qui a été introduit dans Rails 2.3. On lui passe aussi le builder ayant pour nom f. Dans le nouveau partial question_fields on pourra alors utiliser la variable f pour le rendu des éléments du formulaire du modèle Question.

/app/views/surveys/_question_fields.html.erb

 
  <p>
    <%= f.label :content, "Question" %><br />
    <%= f.text_area :content, :rows => 3 %><br />
    <%= f.check_box :_destroy %>
    <%= f.label :_destroy, "Remove Question" %>
  </p>

On peut gérer les champs réponses de la même manière et les mettre dans leur propre partial. Dans le partial _question_fields on va parcourir toutes les réponses de la question and générer un nouveau partial que l’on appellera _answer_fields.

/app/views/surveys/_question_fields.html.erb

 
  <p>
    <%= f.label :content, "Question" %><br />
    <%= f.text_area :content, :rows => 3 %><br />
    <%= f.check_box :_destroy %>
    <%= f.label :_destroy, "Remove Question" %>
  </p>
  <% f.fields_for :answers do |builder| %>
    <%= render ’answer_fields’, :f => builder %>
  <% end %>

Dans notre nouveau partial _answer_fields on va placer le code pour afficher une Answer.

/app/views/survey/_answer_fields.html.erb

 
  <p>
    <%= f.label :content, "Answer" %>
    <%= f.text_field :content %>
    <%= f.check_box :_destroy %>
    <%= f.label :_destroy, "Remove" %>
  </p>

Maintenant que l’on voit les champs réponses, on va modifier l’action new du SurveyController afin que les 3 nouvelles questions ainsi créées aient chacune 4 réponses.

/app/controllers/survey_controller.rb

  def new
    @survey = Survey.new
    3.times do
      question = @survey.questions.build
      4.times { question.answers.build }
    end
  end

A présent, lorsqu’on crée une enquête, on a 3 questions avec chacune 4 réponses.

Quand on remplit les champs et que l’on soumet le formulaire, les réponses ne vont pas s’afficher, mais on peut facilement y remédier. Dans la partie de la vue show pour une enquête qui affiche chaque question, on va rajouter un peu de code pour afficher les réponses à chaque question.

/app/views/survey/show.html.erb

  <ol>
    <% for question in @survey.questions %>
    <li><%= h question.content %></li>
    <ul>
      <% for answer in question.answers %>

        <li><%= h answer.content %></li>
      <% end %>
    </ul>
    <% end %>
  </ol>

Si maintenant on recharge la page de l’enquête, on verra les questions et les réponses.

On n’a pas encore terminé, dans la mesure où on veut être capable d’ajouter ou supprimer des questions ou des réponses dynamiquement sur le formulaire grâce à des liens. C’est ce que nous aborderons dans le prochain épisode.

Méthode dynamique find_by

Thu, 13 May 2010 22:46:24 +0000

C’est un moyen vraiment utile de faire un Find dans Rails. Ci-dessous, vous avez un modèle Task qui recherche les tâches qui ne sont pas accomplies (C’est à dire : la colonne complete est à false).

class TaskController < ApplicationController
    def incomplete
        @tasks = Task.find(:all, :conditions => ['complete = ?', false])
    end

    def last_incomplete
        @task = Task.find(:first, :conditions => ['complete =?', false], :order => 'created_at DESC')
    end
end

Ceci est une meilleure façon de faire avec find_by_all. Remplacez :

@tasks = Task.find(:all, :conditions => ['complete = ?', false])

par

@tasks = Task.find_all_by_complete(false)

Si vous souhaitez trouver une tâche en utilisant find_by, pour trouver la dernière tâche incomplète. La ligne :

@task = Task.find(:first, :conditions => ['complete =?', false], :order => 'created_at DESC')

devient

@task = Task.find_by_complete(false, :order => 'created_at DESC')

La méthode find_by prend le paramètre order comme la méthode find.

Mise en cache des variables d'instance

Thu, 13 May 2010 22:17:23 +0000

	class ApplicationController < ActionController::Base
		def current_user
			User.find(session[:user_id])
		end
	end

La méthode ci-dessus récupère l'utilisateur actuellement connecté. Elle exécute find du modèle User pour le user_id de la session. la méthode est appelée plusieurs fois par requête, ce qui signifie que la base de données est également interrogée plusieurs fois par requête. Ce problème peut être résolu en mettant en cache le résultat de la base de données dans une variable d'instance.

@current_user ||= User.find(session[:user_id])

La chose importante à retenir est le symbole OR. La première fois que la ligne ci-dessus est exécutée, la variable @current_user vaut nil and par conséquent on interrogera la base de données. Pour tous les appels suivants de cette même méthode, @current_user vaudra l'utilisateur actuel et la base de données ne sera pas sollicitée. Cette technique améliore les performances.

	class ApplicationController < ActionController::Base
		def current_user
			@current_user ||= User.find(session[:user_id])
		end
	end

L'action mise à jour avec l'utilisation de la variable d'instance.