Frailers.net: Articles

Utiliser attachment_fu avec la sauvegarde en DB

Thu, 27 Mar 2008 00:00:00 +0100

Introduction

attachment_fu, développé par le célèbre Rick Olson (techno weenie) est un plugin qui vous permet de faciliter la gestion des fichiers téléchargés vers votre application via les formulaires. Il permet ainsi à chaque utilisateur, par exemple, de rajouter sa photo ou son logo sur sa page profil.

Pour ce faire, attachment_fu propose 3 méthodes de stockage:

le système de fichiers: les fichiers sont simplement déposés dans un dossier de votre serveur, idéalement public afin qu’ils puissent ensuite être affichés sur votre site;
Amazon S3: la plateforme de stockage distribuée (et payante) proposée par Amazon;
la base de données: déjà utilisée pour vos autres données.

Le fichier README du plugin documente (relativement) bien les 2 premières solutions, mais ne donne pas beaucoup d’indications sur la dernière. Les avantages proposés par cette solution sont pourtant évidents:

elle permet la centralisation de toutes vos données au même endroit ce qui est bien pratique pour la stratégie de backup;
par rapport à la solution “système de fichiers”, elle évite d’avoir à faire des manipulations supplémentaires si vous déployez avec capistrano (vu que votre dossier d’application rails change à chaque mise à jour);
elle est évidemment gratuite, contrairement à Amazon S3.

L’inconvénient majeur de la solution, à savoir sa lenteur, peut être circonvenu en utilisant un système de caching des fichiers (mais cela sort du cadre de cet article).

Installation du plugin et configuration

Vous aurez tout d’abord besoin de l’une des 3 librairies graphiques suivantes, au choix: RMagick, ImageScience ou minimagick. Ensuite, vous pouvez installer le plugin proprement dit, à partir de la racine de votre application:


script/plugin install http://svn.techno-weenie.net/projects/plugins/attachment_fu/

Nous choisissons de nommer “Avatar” le modèle qui stockera les fichiers téléchargés. Nous créons donc la migration suivante:


class CreateAvatars < ActiveRecord::Migration
  def self.up
    create_table :avatars do |t|
      t.column :filename, :string
      t.column :type, :string
      t.column :content_type, :string
      t.column :size, :integer
      t.column :width, :integer
      t.column :height, :integer
      t.column :parent_id, :integer
      t.column :thumbnail, :string
      t.column :created_at, :datetime
      t.column :db_file_id, :integer
    end
    create_table :db_files do |t|
    end
    execute 'ALTER TABLE db_files ADD COLUMN data LONGBLOB'
  end
  def self.down
    drop_table :avatars
    drop_table :db_files
  end
end

Vous pouvez constater la présence dans la migration d’une table additionnelle nommée “db_files”; elle est imposée par attachment_fu si l’on désire un stockage via base de données. A noter que nous y utilisons un champ de type blob et non binary pour éviter la limite des 65536 caractères imposée par MySQL, ce qui nécessite malheureusement d’effectuer l’ajout de la colonne manuellement en SQL.

Le modèle proprement dit est comme suit:


class Avatar < ActiveRecord::Base
  has_attachment  :storage => :db_file,
                  :content_type => :image,
                  :max_size => 1.megabytes,
                  :thumbnails => { :thumb => "100×100>" }
  validates_as_attachment
end

Enfin, pour afficher nos avatars dans l’application, nous utilisons la méthode show du contrôleur AvatarsController:


class AvatarsController < ApplicationController
  def show
    @avatar = Avatar.find(params[:id])
    send_data(@avatar.current_data,
              :type  => @avatar.content_type,
              :filename => @avatar.filename,
              :disposition => 'inline')
  end
end

Pour afficher un avatar dans vos vues, rien de plus simple:


<%= image_tag avatar_path(@avatar) %>

Bien entendu, il faudrait sans doute également ajouter les méthode create, destroy et compagnie à ce contrôleur ainsi qu’un formulaire d’upload pour que les utilisateurs puissent ajouter/supprimer leurs avatars, mais le fonctionnement n’est pas différent pour le stockage en DB par rapport aux autres techniques, et cela sort donc du cadre de cet article; reportez-vous par example à l’article de Mike Clark pour plus d’info à ce sujet.

Références

Recherche sur un laps de temps avec ActiveRecord

Tue, 25 Mar 2008 00:00:00 +0100

Comme vous le savez, il est possible de définir des conditions sur une recherche ActiveRecord en Ruby au lieu d’une chaîne de caractères. Par exemple, on peut remplacer:


Article.find :all, :conditions => ["published = 1"]

par


Article.find :all, :conditions => {:published => true}

Cela ne marche cependant pour l’instant qu’avec l’égalité (comme l’exemple ci-dessus), les ranges (par exemple {:score => 8..10}, qui génère automatiquement un BETWEEN en SQL) et les tableaux (par exemple {:user_id => [1,4,8]}, qui génère un IN).

Cela marche même avec les ranges d’objets plus compliqués telles que Date ou Time, ce qui simplifie pas mal les recherches sur ce type de champ. Par exemple, pour extraire les articles parus entre il y a un mois et aujourd’hui:


@articles_du_dernier_mois = Article.find(:all,
                            :conditions => {:published_at => 1.month.ago..Time.now})

Nous utilisons ce type de recherche sur Frailers pour extraire les articles parus un mois spécifique donné.

Attachment_fu en batch avec rubyzip

Sun, 09 Mar 2008 00:00:00 +0100

Premièrement, il faut installer rubyzip :

gem install rubyzip

Pas trop difficile jusque là. Vous aurez évidemment besoin de attachment_fu.

script/plugin install http://svn.techno-weenie.net/projects/plugins/attachment_fu/

piston import install http://svn.techno-weenie.net/projects/plugins/attachment_fu/ vendor/

Il ne vous reste plus qu’à ajouter un petit bout de code dans votre contrôlleur:


class AssetsController < ApplicationController
  def create

    Zip::ZipFile.foreach(params[:asset][:uploaded_data].path) do |zip_entry|
      if zip_entry.file?
        ActionController::UploadedTempfile.open(zip_entry.to_s) do |temp|
          zip_entry.extract(temp.path){true}
          temp.original_path = zip_entry.to_s
          temp.content_type = 'image/jpeg' # Juste pour que ça passe dans 
                                           # attachment_fu
          @training_slot.assets.create!(:uploaded_data=>temp)
        end
      end
    end

    flash[:notice] = 'Les images ont été ajoutées correctement.'
    redirect_to ...

  rescue ActiveRecord::ActiveRecordError => e
    flash[:notice] = 'Une erreur s\'est produite : ' + e
    redirect_to ...
  end

Et n’oublliez pas d’importer la librairie dans environnement.rb

require 'zip/zip'

Voilà, c’est tout. En espérant que ça puisse vous éviter le pénible remplissage de galleries. :)

Gestion aisée des plugins avec Piston

Fri, 01 Feb 2008 00:00:00 +0100

Le dossier `vendor`

Le dossier vendor d’une application Rails est destiné à contenir tout ce qui n’est pas développé par vous-même dans le cadre de votre application, à savoir principalement:

les plug-ins, réalisés par la communauté Rails, et placés dans vendor/plugins
une copie du code source de Rails lui-même, placée dans vendor/rails, si vous souhaitez que votre application utilise une version spécifique du framework différente des gemmes présentes dans le système.

Le problème

Le problème survient lorsque vous commencez à utiliser Subversion pour gérer le code source de votre application (c’est votre cas, n’est-ce-pas ?). En cas de mise à jour d’un plugin ou de Rails, vous souhaitez permettre à votre application de se synchroniser à la nouvelle version, mais cela implique de d’abord supprimer le dossier correspondant de votre repository SVN (svn remove), puis installer la nouvelle version dans votre copie locale, et enfin rajouter le nouveau dossier dans le repository (avec svn add). De plus, il n’y a pas de moyen aisé pour s’informer de l’apparition d’une nouvelle mise à jour.

Il y a ceci dit une alternative, fournie par SVN: utiliser la propriété svn:externals pour chaque dossier relatif à un plugin ou à Rails. Cette propriété indique à Subversion que le contenu dudit dossier n’est pas disponible dans le repository mais qu’il doit être téléchargé ailleurs (en l’occurence, dans les différents repositories correspondant aux divers plugins et à Rails).

Le problème avec cette alternative est multiple:

elle consomme un temps bête, puisque la synchronisation avec les repositories extérieure se fait à chaque svn update (pour chaque développeur!);
elle n’est pas facultative: il est donc impossible de signaler que l’on veut ignorer une mise à jour particulière, par exemple en cas d’imcompatibilité de l’application avec la nouvelle version.
si un des repositories externes est très lent, ou tombe en panne, vous perdez du temps ou rendez carrément votre application inutilisable.

La solution: Piston

Piston est une gemme qui se greffe sur les fonctionnalités de SVN pour combiner les avantages des deux systèmes: il vous permet de conserver en local une copie de chaque dépendance externe (plugin, Rails, ou autre), tout en rendant possible les mises à jour, uniquement si et quand vous le désirez.

Commençons par installer Piston:


$ sudo gem install piston

Il est dès lors possible, à partir de la racine de votre application, d’importer un plugin:


$ piston import http://svn.techno-weenie.net/projects/plugins/restful_authentication/ vendor/plugins/restful_authentication
Exported r3119 from 'http://svn.techno-weenie.net/projects/plugins/restful_authentication/' to 'vendor/plugins/restful_authentication'

Piston télécharge le dossier et le marque pour ajout dans le repository (svn add); il sera rajouté dans votre repository lors du prochain commit (svn commit). Vous êtes alors dans la situation d’une copie purement locale à votre repository (aucune dépendance à un repository externe), à ceci près qu’il est possible de vérifier si une mise à jour d’un dossier est disponible, au moyen de la commande piston status. Prenons par exemple le cas d’une application où l’on aurait rajouté Rails 2.0.2 et restful_authentication, ce dernier ayant une mise à jour:


$ piston status
     vendor/rails (http://svn.rubyonrails.org/rails/tags/rel_2-0-2/)
M    vendor/plugins/restful_authentication (http://svn.techno-weenie.net/projects/plugins/restful_authentication/)

Dans notre exemple, la lettre “M” placée devant le plugin restful_authentication nous indique qu’il a été mis à jour. Il est alors simple d’installer cette mise à jour:


$ piston update vendor/plugins/restful_authentication

Pour mettre à jour l’entièreté du dossier vendor, il suffit de lancer la commande piston update.

Resources

Editer plusieurs modèles avec fields_for

Wed, 23 Jan 2008 00:00:00 +0100

Le problème

Prenons l’exemple habituel du blog.


class Post < ActiveRecord::Base
  belongs_to :author
end

class Author < ActiveRecord::Base
  has_many :posts
end

Chaque Post est écrit par un Author. Dans le formulaire de création de Post, les champs name et email de l’auteur sont inclus. Nous voudrions créer à la volée un enregistrement Author dans la base de données au moment de la création de Post. Pour le moment, notre application ressemble à ceci.

Vue du formulaire `(app/view/posts/_form.html.erb)` :


<p> <b>Title</b><br /> <%= f.text_field :title %> </p>

<p> <b>Content</b><br /> <%= f.text_area :content %> </p>

<p> <b>Name</b><br /> <%= text_field_tag :name, @post.author.name %> </p>

<p> <b>Email</b><br /> <%= text_field_tag :email, @post.author.email %> </p>

Action `create` dans `PostsController` `(app/controllers/posts_controller.rb)` :


def create
  @post = Post.new(params[:post])
  @post.author = Author.new(:name => params[:name], :email => params[:email])

  respond_to do |format|
    if @post.save
      # response code
    end
  end
end

La solution

Nous désirons simplifier la vue et le contrôleur. La principale cause de désagrément est l’organisation des attributs envoyés par le formulaire :

  { "name"=>"Jean-Baptiste Escoyez",
    "email"=>"jbe at belighted point com",
    "post"=>{
      "title"=>"Editer plusieurs modèles avec fields_for", 
      "content"=>"Contenu..."}}

Nous voyons que name et email ne sont pas associés à post. De ce fait, nous sommes obligés de créer un Author dans le contrôleur.

Nous utilisons fields_for pour nous aider à organiser les arguments.

Vue du formulaire `(app/view/posts/_form.html.erb)`:


<p> <b>Title</b><br /> <%= f.text_field :title %> </p>

<p> <b>Content</b><br /> <%= f.text_area :content %> </p>

<% fields_for :author, @post.author do |af| %>
  <p> <b>Name</b><br /> <%= af.text_field :name %> </p>

  <p> <b>Email</b><br /> <%= af.text_field :email %> </p>
<% end %>

Action `create` dans `PostsController` `(app/controllers/posts_controller.rb)`:


def create
  @post = Post.new(params[:post])
  @post.author = Author.new(params[:author])

  respond_to do |format|
    if @post.save
      # response code
    end
  end
end

Remarquez le second argument de fields_for. Il s’agit de l’objet qui donnera les valeurs aux champs name et email au moment de l’édition du post. Le contrôleur a également changé car les arguments envoyés par le formulaire sont maintenant organisés différemment.

  { "author"=>{
      "name"=>"Jean-Baptiste Escoyez",
      "email"=>"jbe at belighted point com"},
    "post"=>{
      "title"=>"Editer plusieurs modèles avec fields_for", 
      "content"=>"Contenu..."} }

Encore mieux !

Nous pouvons aller encore plus loin dans notre refactorisation. En changeant fields_for par f.fields_for, vous allez imbriquer les attributs des deux objets.

  { "post"=>{
      "name"=>"Jean-Baptiste Escoyez",
      "email"=>"jbe at belighted point com",
      "author"=>{
        "title"=>"Editer plusieurs modèles avec fields_for", 
        "content"=>"Contenu..."} } }

Comme une des clefs du hash est author, la méthode author= de post sera appelée lorsque vous appellerez Post.new(params[:post]). Malheureusement, la méthode author n’est pas prévue pour prendre un hash en paramètre mais un objet Author. Il faut donc remplacer f.fields_for :author par f.fields_for :author_attributes et créer une méthode author_attributes= dans le modèle Post ; comme la méthode author_attributes= est semblable à build_author, un alias de méthode suffit:


class Post < ActiveRecord::Base
  belongs_to :author
  alias author_attributes=  build_author
end

Vous pouvez dès lors supprimer la ligne post.author = Author.new(params[:author]) dans votre contrôleur.


def create
  @post = Post.new(params[:post])
  @post.author = Author.new(params[:author])

  respond_to do |format|
    if @post.save
      # response code
    end
  end
end

fields_for peut être utilisé de manière imbriquée si vous avez plusieurs modèles à créer/éditer. N’oubliez pas le f. avant fields_for si vous voulez imbriquer les attributs.

fields_for peut également être utilisé sans modèle correspondant, juste pour structurer l’information envoyée par un formulaire. Depuis que j’utilise fields_for, j’ai complètement laissé tomber les FormTagHelper.

Rails et l'iPhone

Fri, 21 Dec 2007 00:00:00 +0100

Il y a quelques temps, j’ai eu la chance de mettre la main sur un iPhone et je suis très vite tombé amoureux de l’engin: malgré l’écran de (relativement) petite taille par rapport à celui d’un ordinateur classique, le browser Safari est particulièrement fabuleux et ouvre de nouvelles perspectives au surf mobile. C’était donc pour moi un devoir d’essayer de faire tourner une application Rails dessus; voici donc quelques conseils pour ce faire.

iPhoney

Tout d’abord, si vous développez sur OSX, téléchargez vite iPhoney: il s’agit d’une petite application qui simulera l’apparence de votre site dans le navigateur Safari 320×480 pixels de l’iPhone. Cela vous permettra de voir immédiatement le résultat de vos développements sans devoir systématiquement faire un refresh sur votre iPhone (voire carrément d’en acheter un, si vous êtes dans un pays où l’iPhone n’est pas encore disponible… hum hum).

MIME-type iPhone

Créez un alias MIME-type pour l’iPhone en utilisant les initialiseurs de Rails 2 :


# config/initializers/mime_types
Mime::Type.register_alias "text/html", :iphone

Détection de l’iPhone

La recommandation officielle d’Apple, lors de la détection d’un navigateur client de type iPhone, est de non pas rediriger vers une version du site faite pour iPhone, mais plutôt de montrer le site dans sa version “normale” en proposant un lien vers la version iPhone. La raison pour cela est que les utilisateurs d’iPhone sont habitués à naviguer sur l’entièreté du web et ne veulent être contraint à n’avoir accès qu’à un sous-ensemble limité.

Pour effectuer la détection de l’iPhone, Apple recommande de chercher la chaîne de caractères “Mobile Safari” (et non “iPhone” ou “iPod Touch”, ceci afin de rester ouvert à d’éventuels autres appareils dans le futur). Une solution est donc d’ajouter à votre application_helper.rb la méthode suivante:


# Détection d'une requête iPhone ou iPod touch (navigateur Mobile Safari)
def iphone_user_agent?
  request.env["HTTP_USER_AGENT"] &&
  request.env["HTTP_USER_AGENT"][/(Mobile\/.+Safari)/]
end

Dans votre vue, montrez un message pour les navigateurs iPhone pointant vers la version adaptée:


<% if iphone_user_agent? -%>
<div class="message">
  <p>
    Vous naviguez à partir d'un iPhone?
    <a href="http://iphone.monsite.com/">Utilisez la version optimisée</a>.
  </p>
</div>
<% end -%>

Sous-domaine iPhone

Donc, plutôt que de forcer l’adaptation du site à l’iPhone, nous proposons cette option via un sous-domaine alternatif (avec un lien retour au cas où l’utilisateur voudrait malgré tout voir le site “normal”). A vous de configurer votre serveur DNS pour permettre cette possibilité. Pour le développement en local, une solution est de simplement éditer votre fichier /etc/hosts et y rajouter la référence à ce nom de domaine fictif:


127.0.0.1 iphone.monsite.com

Ajustement du format à l’iPhone

Ces quelques méthodes privées permettent d’automatiquement appliquer le format pour iPhone si celui-ci est détecté:


class ApplicationController < ActionController::Base

    before_filter :adjust_format_for_iphone

private

  # Utiliser le format iPhone si la requête est faite
  # au sous-domaine iphone.monsite.com
  def adjust_format_for_iphone    
    request.format = :iphone if iphone_request?
  end

  # Renvoie true pour les requêtes vers requests to iphone.monsite.com
  def iphone_request?
    return (request.subdomains.first == "iphone" ||
            params[:format] == "iphone")
  end

end

Gestion de l’orientation

L’iPhone permet aux utilisateurs de naviguer sur le web en mode portrait comme en mode paysage. Cette fonctionnalité peut avoir un énorme impact sur votre application. En effet, vous pourriez d’une part vouloir adapter vos CSS en fonction de l’orientation (position des menus, des publicités, etc.), et d’autre part, utiliser Ruby pour suivre quelle orientation vos utilisateurs préfèrent.

Pour l’instant, il n’y a malheureusement pas de solution élégante au problème. Une solution est de sonder de manière régulière l’orientation actuelle de l’iPhone via JavaScript, et réagir en cas de changement. Par exemple, le code suivant vérifie 5 fois par seconde l’orientation actuelle et met à jour un attribut de la balise body appelé “orientation” :


currentWidth = 0;
window.setInterval( 'checkMyOrientation()', 200 );

function checkMyOrientation() {
 if (window.innerWidth != currentWidth) {
  currentWidth = window.innerWidth;
  var myOrientation = (currentWidth == 320) ? "upright" : "landscape";
  document.body.setAttribute("orientation", myOrientation);
  }
};

Cet attribut “orientation” n’est pas un attribut standard mais cela est permis dans les CSS. Il est ainsi possible de définir en CSS un look tout à fait différent suivant l’orientation, avec les sélecteurs body[orientation="upright"] et body[orientation="landscape"], et ce entièrement du côté client.

Si, par contre, les changements à faire sont plus conséquents et nécessitent l’intervention du serveur, libre à vous de remplacer la ligne mettant à jour l’attribut “orientation” par un appel AJAX.

Empêcher le zoom

Même si c’est, en quelque sorte, imposer une contrainte sur l’expérience utilisateur de votre application, il est possible que vous souhaitiez désactiver le zoom disponible sur Mobile Safari. Cela peut servir, par exemple, si vous souhaitez rendre aussi discret que possible le côté “page web” de votre application et simuler le comportement d’une application iPhone native. Pour désactiver le zoom, utilisez user-scalable=no :


<meta name="viewport" content="user-scalable=no" />

Liens vers un numéro de téléphone

En principe, l’iPhone détecte automatiquement les numéros et les convertit si nécessaire, ce qui vous permet d’appeler un numéro indiqué sur une page rien qu’en cliquant dessus. Evidemment, l’iPhone ne reconnaît pas tous les formats de numéros de téléphone et il est possible que vous vouliez permettre un appel via un lien sans afficher platement le numéro sur la page.

Pour ce faire, le format “tel:” est reconnu par Mobile Safari; il fonctionne de la même manière que le fameux “mailto:”, et vous permet d’appeler un numéro en cas de clic tout en permettant de rendre le lien plus descriptif: <a href="tel:33612345678">Pierre</a>.

Utilisation d’iUI et création de vues pour iPhone

Pour conclure, parlons du framework iUI, basé sur le travail de Joe Hewitt, qui simplifie énormément le développement d’applications web pour iPhone. Il suffit d’inclure les fichiers JavaScript et CSS d’iUI et suivre certaines conventions dans les vues pour simuler un comportement iPhone natif, tels que les menus coulissants et les rechargements AJAX.

Rails 2 rend triviale la création de vues différentes en fonction du format, y compris les layouts. Voici un exemple de layout pour iPhone (app/views/layouts/application.iphone.erb) qui utilise les conventions pour iUI:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <meta id="viewport" name="viewport" content="width=320;
      initial-scale=1.0; maximum-scale=1.0; user-scalable=0;"/>
    <title><%= @page_title -%></title>
  <%= stylesheet_link_tag 'iui' %>
  <%= javascript_include_tag 'iui' %>
</head>
<body>
    <div class="toolbar">
        <h1 id="pageTitle"></h1>
        <a id="backButton" class="button" href="#"></a>
    </div>

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

En ce qui concerne les vues, il faut s’adapter aux conventions d’iUI. Les liens “normaux” sont chargés via AJAX et provoquent un “glissement latéral” de la page vers la vue de destination. Il est possible de spécifier target="_self" pour remplacer la page entière, ou target="_replace" pour remplacer l’élément avec la réponse AJAX.

Exemple:

index.iphone.erb


<ul title="Bienvenue" selected="true">
    <li><%= link_to 'Action exemple', example_path %></li>
    <li><%= link_to 'Déconnexion', logout_path, :method => :delete,
            :target => '_self' %></li>
</ul>

show.iphone.erb


<div class="panel" title="Exemple" selected="true">
    <h2>Contenu exemple</h2>
    <p>Voici du contenu</p>
</div>

Attention: comme iUI charge toujours le contenu via AJAX, le layout ne doit être chargé que pour la première page. Toutes les requêtes suivantes doivent utiliser render :layout => false (sauf dans le cas particulier target="_replace" qui charge une nouvelle page). Si vous observez des bizarreries dans le rendu de certaines pages, c’est probablement à cause de cette particularité.


respond_to do |format|
    format.iphone do  # action.iphone.erb
      render :layout => false
    end
end

Bien entendu, rien ne vous oblige à utiliser iUI et dans pas mal de cas, ce framework s’avèrera trop restrictif. Mais si vous aimez le “look’n’feel” de l’interface proposée sur l’iPhone, iUI vous permet d’avoir celui-ci sur votre site en vous épargnant tous les petits détails techniques.

Resources

Cet article est essentiellement une combinaison/traduction des ressources anglophones suivantes:

Les pages suivantes vous donneront des informations additionnelles:

Plugin de la semaine : Rails Widgets (2)

Wed, 12 Dec 2007 00:00:00 +0100

Les gestionnaires de visibilité

Ce que j’appelle ici un gestionnaire de visibilité est simplement le code javascript nécessaire à ajouter pour cacher ou montrer un élément du DOM d’une page web donnée.

On rencontre souvent cette fonctionnalité lorsqu’on affiche un liste d’éléments et qu’on désire afficher/cacher les éléments de cette liste.

Widgets permet de créer extrêmement rapidement un bloc de détails que l’utilisateur peut afficher ou cacher.

Après avoir installé le plugin comme décrit dans le précédent article, il suffit d’ajouter ces quelques lignes de code:


<% for element in @list %>
  <div class="element">
    <%= h element.info %>
     <%= show_detail_for element %>

    <% detail_for element do %>
      Plus de détails...
      <%= h element.detailed_info %>

      <%= hide_detail_for element %>
    <% end %>
  </div>
<% end %>

N’oubliez pas d’inclure les javascripts par défaut et particulièrement la librairie prototype dans votre vue.


<%= javascript_include_tag :defaults %>

Profitez du résultat.

Les info-bulles

Avec Widgets, il devient aussi aisé de créer des info-bulles.


<% tooltip "info" do %>
  <h3>Titre de mon info-bulle</h3>
  Contenu...
<% end %>

A la place de la chaine de caractère, vous pouvez, bien entendu, passer une image grâce à image_tag.

Si vous préférez rapatrier le contenu de l’info-bulle à la volée grâce à AJAX, c’est aussi possible.


<% 
tooltip do |t|
  t.named image_tag('info') || 'info' 
  t.link_to_remote :action => 'show_tooltip'
end
%>

Et voilà de quoi simplifier encore un peu plus vos vues. Qu’en pensez-vous? Nous verrons encore deux fonctionnalités de ce plugin la semaine prochaine.

Ressources : Présentation de Rails Widgets par son créateur : Paolo Dona

Plugin de la semaine: Rails Widgets (1)

Tue, 04 Dec 2007 00:00:00 +0100

Le plugin Widgets rassemble plusieurs helpers qui permettent d’ajouter facilement des éléments d’interface graphique à vos pages. Aujourd’hui, 7 éléments sont disponibles :

Les onglets (Tabnav)
Les liens de navigation (Navigation)
Le gestionnaire de visibilité (Show/Hide)
La présentation en table (Tableizer)
Les icônes info (Tooltips)
La mise en page en colonne (ColumnLayout)
Les menus contextuels (Nubbins)

Pourquoi ce projet est-il tellement prometteur?

Aujourd’hui, les technologies web permettent de concevoir des contrôles graphiques (widgets) de manière tout à fait différente grâce au couple HTML-Javascript. (voir le billet à propos de Songza chez Fred Cavazza). Le projet Widget permet non seulement de “webiser” (j’entends par là transformer en html/javascript) les contrôles graphiques “traditionnels” (TabNav, Tooltip) mais aussi d’en créer des nouveaux (Nubbins, Navigation) propres au web, le tout de manière très DRY.

Ce projet est maintenu par Paolo Dona, de la société italienne Seesaw.

Trêve de discussions, passons à la pratique.

Installation du plugin

Comme d’habitude :


ruby script/plugin install svn://svn.seesaw.it/widgets/trunk


piston import svn://svn.seesaw.it/widgets/trunk vendor/plugins/widgets

si vous utilisez piston.

Installer TabNav:

Le widget TabNav permet de créer en quelques secondes de magnifiques onglets pour votre site. Pour commencer, il faut générer le partial qui représentera les onglets:


ruby script/generate tabnav nom_de_la_bar_donglets

Cette commande crée le partial _nom_de_la_bar_donglets_tabnav.rhtml dans app/views/widgets. Il ne reste plus qu’à ajouter les onglets dans vos vues:


<% tabnav :nom_de_la_bar_donglets do %>
 # Placez le contenu ici
<% end %>

On ajoutera généralement ce code dans application.html.erb ou plus généralement dans un layout. Le contenu sera alors simplement <%= yield %>.

A ce stade, vous pouvez lancer votre application et voir apparaitre les onglets dont les noms correspondent à ceux de vos différents contrôleurs.

Personnaliser ses onglets

Les noms que vous donnerez à vos contrôleurs ne sont pas ceux que vous souhaitez donner à vos onglets? Pas de problèmes. Il suffit d’éditer le partial _nom_de_la_bar_donglets_tabnav.rhtml qui doit ressembler à ceci:


<%  
render_tabnav :nom_de_la_bar_donglets_tabnav, 
              :generate_css => false, 
              :html => {:class=> 'myCssClass', :id=>'myCssId'} do  

  add_tab do |t|
    t.named 'Accueil'
    t.titled 'Home Page'
    t.links_to :controller=>'static', :action=>'index'
    t.highlights_on :controller=>'users', :action=>'new'
    t.highlights_on :controller=>'account'
  end 
end
%>

Les arguments de render_tabnav sont évidents :

Le premier est le nom de la bar d’onglets.
:generate_css détermine si les feuilles de style doivent être “inline” ou non (par défaut).
:html est un hash de toutes les options HTML à passer à la barre d’onglets.

Les différentes méthodes de l’onglet vont permettre de définir son comportement. La méthode named définit le nom qui apparaitra sur l’onglet. La méthode titled définit la valeur de l’option HTML alt. La méthode links_to est un lien vers la méthode correspondante dans ActionView et définit la cible de l’onglet.

Enfin, la méthode highlights_on permet de définir quand un onglet sera affiché comme “actif”. Dans l’exemple, l’onglet sera “activé” lorsque le contrôleur est static et l’action index, lorsque le contrôleur est users et l’action new ou encore lorsque le contrôleur est account.

La barre d’onglets sans cadre

Par défaut, Tabnav affiche un cadre autour du contenu de l’onglet. Si vous désirez que vos onglets n’encadrent pas leur contenu, il suffit de modifier la manière dont vous insérez les onglets:


<% tabnav :nom_de_la_bar_donglets %>

au lieu de


<% tabnav :nom_de_la_bar_donglets do %>
 # Placez le contenu ici
<% end %>

Conclusion

Voilà, j’espère que ces petites astuces vous auront fait gagner pas mal de temps de développement. La semaine prochaine, je vous ferai découvrir d’autres widgets. Avez-vous des idées d’autres widgets que vous utilisez tous les jours?

Jointures multiples dans ActiveRecord grâce à include

Thu, 22 Nov 2007 00:00:00 +0100

Rails est génial. Mais quand les choses se compliquent, ses détracteurs disent que le framework est limité. J’y ai cru un instant lorsque j’ai rencontré le problème que je vous décris ci-dessous. J’ai finalement constaté que Rails était génial même dans les situations compliquées.

Pour exposer le problème, rien de tel qu’un petit exemple:

L’application qui me pose problème est destinée à gérer un ensemble de bibliothèques (Library) contentant plusieurs livres (Book) qui eux-même ont un ou plusieurs auteurs (Author). Un auteur peut bien entendu avoir écrit plusieurs livres et un livre peut se trouver dans plusieurs bibliothèques (le lecteur attentif aura compris que nous ne parlons pas de l’exemplaire du livre mais bien de son édition).

Pour mettre en avant la cardinalité multiple, nous allons utiliser has_many :through. Nous créons donc deux tables de jointure : “propriété” (Ownership) pour joindre bibliothèque et livre et “autorat” (Authorship) pour joindre livre et auteur.

Le modèle est le suivant :


class Library < ActiveRecord::Base
  has_many :ownerships
  has_many :books, :through => :ownerships
end

class Book < ActiveRecord::Base
  has_many :ownerships
  has_many :libraries, :through => :ownerships

  has_many :authorships
  has_many :authors, :through => :authorships
end

class Author < ActiveRecord::Base
  has_many :authorships
  has_many :books, :through => :authorships
end

Et les tables de jointure:


class Ownership < ActiveRecord::Base
  belongs_to :library
  belongs_to :book
end

class Authorship < ActiveRecord::Base
  belongs_to :book
  belongs_to :author
end

Dans notre exemple, nous voulons simplement récupérer la liste de tous les auteurs d’une bibliothèque.


class Library < ActiveRecord::Base
  has_many :ownerships
  has_many :books, :through => :ownerships

  def find_all_authors
    books.inject([]){|authors,book| authors + book.authors}.uniq
  end
end

L’opération que nous faisons ici est potentiellement très lourde. En effet, elle va générer autant de requêtes SQL qu’il y a de livres dans la bibliothèque (lors de l’appel à book.authors).

En SQL, nous aurions fait une jointure multiple pour récupérer l’information recherchée. Allons-nous devoir utiliser find_by_sql? Lorsque je me suis retrouvé confronté à ce problème, j’ai bien pensé que j’allais devoir y passer. Mais, comme je le disais, Rails est génial.

L’option Activerecord utilisée ici est :include. D’habitude, :include est utilisée pour précharger les objets associé à un objet donné. Ce que réalise cette option est en réalité une jointure externe à droite. Il ne reste alors plus qu’à poser les bonnes :conditions pour obtenir le résultat désiré.


class Library < ActiveRecord::Base
  has_many :ownerships
  has_many :books, :through => :ownerships

  def find_all_authors
    Author.find(:all, :include => [:books => :libraries], 
                      :conditions => ["libraries.id = ?", self.id])
  end
end

Plusieurs remarques peuvent être faites à propos de ce exemple:

Nous utilisons la version imbriquée de include. En effet, la table Author sur laquelle nous faisons la requête ne contient aucune référence vers libraries.

Nous n’avons pas besoin de mentionner les classes d’associations (ownership et authorship) dans include, elle seront automatiquement ajoutées par rails.

Dans la condition, "libraries" est écrit au pluriel pour désigner le nom de la table.

Les imbrications du include peuvent être réalisées autant de fois que désiré et peuvent être combinées. Cependant, bien que cette technique permette de réaliser un nombre important de requêtes en une seule, il ne faut pas oublier que l’opération JOIN en SQL est lourde et qu’il faut donc essayer de l’éviter tant que possible.

Pour cloturer ce billet, je préciserai que je n’ai trouvé que très peu d’informations sur :include tant au niveau de la communauté anglophone que francophone. Ai-je raté un point important? Y a-t-il une solution plus élégante? Et vous, comment faites-vous?

Gabarits imbriqués avec le plugin nested_layouts

Mon, 19 Nov 2007 00:00:00 +0100

Fonctionnement des gabarits dans Rails

Pour rappel, Rails fournit un système astucieux de gabarits de pages (templates). Si vous nommez une vue “application.html.erb” dans le dossier “app/views/layouts”, celle-ci sera utilisée comme gabarit de page pour l’ensemble des vues présentes dans votre site. Pour spécifier dans ce gabarit l’endroit où la vue particulière doit intervenir, vous faites usage du mot-clef yield. Dans l’exemple qui suit, la phrase “Bonjour!” propre à l’action index du contrôleur “MonControleur” suivra le titre “Bievenue sur mon site” présent dans le gabarit général de l’application:


# app/views/layouts/application.html.erb
<html>
  <body>
    <h1>Bienvenue sur mon site</h1>
    <%= yield %>
  </body>
</html>

# app/views/mon_controleur/index.html.erb
Bonjour!

De plus, si vous souhaitez utiliser un gabarit différent d’un contrôleur à l’autre, il est possible de créer une vue du nom de contrôleur dans ce même dossier “app/views/layouts” et toutes les actions de ce contrôleur utiliseront par défaut ce gabarit. Cela permet d’avoir un gabarit particulier pour chaque partie de votre application, ce qui s’avère souvent utile pour afficher des sous-menus (comme un menu “catégories” dans un contrôleur “produits”), par exemple.

Le problème est que, dans ce cas, Rails utilise ce gabarit au lieu du gabarit général (qui est alors simplement ignoré), ce qui peut-être embêtant étant donné que la plupart du temps, l’ensemble de votre application garde malgré tout un design commun (logo, menu général, footer, etc.).

On voudrait donc pouvoir garder ce gabarit commun, tout en permettant l’usage d’un sous-gabarit propre. C’est là qu’intervient le plugin Nested Layouts.

Le plugin Nested Layouts

Ce plugin est très simple (il ne fait pas 30 lignes de code). Commencez tout d’abord par l’installer (et n’oubliez pas de redémarrer votre serveur ensuite, pour le charger):


script/plugin install svn://rubyforge.org/var/svn/nested-layouts/trunk/nested_layouts

Vous pouvez maintenant spécifier des sous-gabarits. Votre application.html.erb reste identique à auparavant:


# app/views/layouts/application.html.erb
<html>
  <body>
    <h1>Bienvenue sur mon site</h1>
    <%= yield %>
  </body>
</html>

De même que vos vues propre à chaque action:


# app/views/mon_controleur/index.html.erb
Bonjour!

La différence est que maintenant, vous pouvez appeler le gabarit général à partir d’un sous-gabarit, dans notre exemple celui propre au contrôleur “mon_controleur” :


# app/views/layouts/mon_controleur.html.erb
<% inside_layout 'application' do -%>
  <h2>Mon sous-menu</h2>
  <ul>
    <li>Element 1</li>
    <li>Element 2</li>
  </ul>
  <%= yield %>
<% end -%>

Votre action index affichera dès lors “Bonjour!” dans le sous-gabarit de “mon_controleur”, lui même inclus dans le gabarit général, ce qui donnera ceci en sortie:


<html>
  <body>
    <h1>Bienvenue sur mon site</h1>
    <h2>Mon sous-menu</h2>
    <ul>
      <li>Element 1</li>
      <li>Element 2</li>
    </ul>
    Bonjour!
  </body>
</html>

En bonus, il est même possible de passer des données du sous-gabarit vers le gabarit général, et ce au moyen de la variable @other_data_for_outer_layout:


# app/views/layouts/mon_controleur.html.erb
<% inside_layout 'application' do -%>
  <% @other_data_for_outer_layout = 'coucou' -%>
  <%= yield %>
<% end -%>

# app/views/layouts/application.html.erb
<html>
  <body>
    <h1>Bienvenue sur mon site</h1>
    <p>Message du contrôleur : <%= @other_data_for_outer_layout %></p>
    <%= yield %>
  </body>
</html>

Références

NestedLayouts

Frailers.net: Articles

Utiliser attachment_fu avec la sauvegarde en DB

Introduction

Installation du plugin et configuration

Références

Recherche sur un laps de temps avec ActiveRecord

Attachment_fu en batch avec rubyzip

Gestion aisée des plugins avec Piston

Le dossier vendor

Le problème

La solution: Piston

Resources

Editer plusieurs modèles avec fields_for

Le problème

Vue du formulaire (app/view/posts/_form.html.erb) :

Action create dans PostsController (app/controllers/posts_controller.rb) :

La solution

Vue du formulaire (app/view/posts/_form.html.erb):

Action create dans PostsController (app/controllers/posts_controller.rb):

Encore mieux !

Rails et l'iPhone

iPhoney

MIME-type iPhone

Détection de l’iPhone

Sous-domaine iPhone

Ajustement du format à l’iPhone

Gestion de l’orientation

Empêcher le zoom

Liens vers un numéro de téléphone

Utilisation d’iUI et création de vues pour iPhone

Resources

Plugin de la semaine : Rails Widgets (2)

Les gestionnaires de visibilité

Les info-bulles

Plugin de la semaine: Rails Widgets (1)

Installation du plugin

Installer TabNav:

Personnaliser ses onglets

La barre d’onglets sans cadre

Conclusion

Jointures multiples dans ActiveRecord grâce à include

Gabarits imbriqués avec le plugin nested_layouts

Fonctionnement des gabarits dans Rails

Le plugin Nested Layouts

Références

Le dossier `vendor`

Vue du formulaire `(app/view/posts/_form.html.erb)` :

Action `create` dans `PostsController` `(app/controllers/posts_controller.rb)` :

Vue du formulaire `(app/view/posts/_form.html.erb)`:

Action `create` dans `PostsController` `(app/controllers/posts_controller.rb)`: