Frailers.net

Une interface d'administration en 2 secondes : Typus

Wed, 22 Jul 2009 00:00:00 +0000

Pour la plupart des projets, il est nécessaire d’avoir une interface d’administration. Dans la majeure partie des cas, il s’agit simplement d’un accès aux objets. Permettre à l’administrateur de créer, d’éditer ou de supprimer certains objets. Au lieu de recréer vos contrôleurs et vues pour chaque projets, je vous propose une petite introduction à Typus, qui va nous générer tout ça comme un grand à partir de nos modèles :D

Etape 1 : Installer Typus

   1  # script/plugin install git://github.com/fesplugas/typus.git
   2  # script/generate typus

Une fois les fichiers créés il suffit d’exécuter la migration. Elle ajoute une table contenant les utilisateurs de typus à votre base de donnée. Typus a donc son propre système de gestion d’utilisateurs.

   1  # rake db:migrate

Et voilà, il ne vous reste plus qu’a vous rendre à l’adresse

   1  http://localhost:3000/admin

Pour accéder à votre nouvelle interface d’administration !

Mieux que la tente Quechua…

Etape 2 : Configurer Typus

Evidement, dans sa forme actuelle, même si Typus nous a fait gagner du temps, il reste quelques petits problèmes. Nous voudrions par exemple :

Empêcher l’édition des objets d’un modèle précis
Empêcher la création d’un type d’objet
Enlever un champ particulier du formulaire d’édition
Rendre un champ ‘read-only’ dans le formulaire
etc…

Pas de panique c’est possible, il suffit d’aller dans les fichiers :

config/typus/application.yml
config/typus/application_roles.yml

Prenons un exemple, un blogpost, dans application.yml on aura :

   1  Post:
   2    fields:
   3      list: id, blog, user, content, status, created_at
   4      form: blog, user, content
   5      show: id, blog, user, content, status, updated_at, created_at
   6   options:
   7      read_only: blog, user
   8    export: csv, xml
   9    order_by: user
  10    filters: created_at
  11    search: content
  12    application: exampleblog

Fields permet de définir, pour les vues générées, les champs qui y seront présents. On peut également spécifier quels champs seront ‘read-only’ grâce à ‘options > read-only’ comme aux lignes 6 et 7.

Export permet de spécifier dans quel format la liste des éléments sera exportable, xml, csv et pdf sont disponibles.

Order_by est suffisement explicite. Filters crée, sur le côté droit de la liste, une boîte qui permet de filtrer les éléments. Si on prend l’exemple du created_at on aura une série de liens (Today, Past 7 days, This month, This year) qui permettent de filtrer notre liste.

Search ajoute également une boîte sur la droite, une zone de recherche. On peut rechercher sur plusieurs champs.

Si vous souhaitez modifier complètement une des vues générées, c’est simple, si on prend notre exemple et qu’on souhaite modifier le formulaire, il suffit de créer le fichier app/view/admin/posts/edit.html.erb, d’en écrire le contenu et l’affaire est dans le sac !

Le fichier application_roles.yml permet de spécifier, pour chaque rôle, les actions qu’il pourra effectuer sur tel ou tel objet.

   1  admin:
   2    Post: create, read, delete, update

Le layout de typus est également modifiable a souhait, et il existe encore d’autres options non détaillées dans ce post. Consultez la doc pour plus d’infos.

Dorénavant, vous n’avez plus d’excuses pour ne pas faire des interfaces d’administration qui en jettent en très peu de temps ;)

http://intraducibles.com/projects/typus/
http://github.com/fesplugas/typus/tree/master

Deuxième edition d'ArrrrCamp

Fri, 26 Jun 2009 00:00:00 +0000

ArrrrCamp – “About Ruby, Rails, Radiant and Rum”-Camp, le rendez-vous Ruby en Belgique. Après une première edition le 8 mai dernier, les organisateurs d’ ArrrrCamp remettent le couvert. Rendez-vous le 16 Octobre 2009.

ArrrrCamp tente de rassembler toute les personnes qui, en Belgique (et ailleurs), ont un intérêt pour Ruby et ses dérivés. La première edition fût un succès. Pour en savoir plus, le site d’ ArrrrCamp reprend les slides/videos des différentes présentations qui ont eu lieu lors de la première edition.

http://arrrrcamp.be

Les inscriptions pour la deuxième edition ont commencé, déjà 11 inscrits ! Venez grossir les rangs des participants !

http://arrrrcamp.be/participants/new

Voilà une bonne occasion de parler de votre passion, le tout autour d’un bon verre ;)

Si vous souhaitez sponsoriser l’évènement, il suffit de vous rendre sur le site d’ ArrrrCamp et de contacter l’équipe.

Importez vos contacts avec le plugin Contacts

Wed, 24 Jun 2009 00:00:00 +0000

Si vous travaillez sur des réseaux sociaux, ou si simplement vous souhaitez que votre application permette à vos utilisateurs d’inviter un maximum de personnes, alors Contacts peut vous aider. Ce plugin vous permettra de récupérer la liste des contacts de vos utilisateurs, à partir d’un compte Hotmail, Gmail, Yahoo ou Plaxo.

Etape 1 : Installer Contacts

Contacts a été initialement créé par cardmagic mais les versions que j’ai eu l’occasion d’utiliser ne fonctionnaient plus avec Hotmail. Je vous conseille donc d’utiliser le fork de waheedi qui règle le problème.

   1  script/plugin install git://github.com/waheedi/contacts.git

Etape 2 : Récupérer les contacts

L’utilisation de contacts est ridiculement simple.

   1  # vous connaissez la plateforme concernée
   2  Contacts::Hotmail.new(login, password).contacts
   3  Contacts::Yahoo.new(login, password).contacts
   4  Contacts::Gmail.new(login, password).contacts
   5    
   6  Contacts.new(:gmail, login, password).contacts
   7  Contacts.new(:hotmail, login, password).contacts
   8  Contacts.new(:yahoo, login, password).contacts
   9  
  10  # laisser contacts deviner de quel type de compte il s'agit
  11  Contacts.guess(login, password).contacts

Vous récupérez alors un tableau de contacts de la forme :

   1  [["name", "foo@bar.com"], ["name2", "foo2@bar2.com"]]

A vous de jouer !

Plus d’infos sur le fork de contacts par waheedi ici :
http://github.com/waheedi/contacts/tree/master

Babilu : I18n dans votre javascript !

Tue, 16 Jun 2009 00:00:00 +0000

Babilu est un plugin très facile à utiliser qui copie littéralement votre configuration I18n en JSON et Javascript. Cela vous permet d’utiliser vos traductions côté client, et c’est parfois assez pratique…

Etape 1 : Installer Babilu et ses dépendances

Babilu a besoin de Lucy pour fonctionner.

   1  script/plugin install git://github.com/toretore/lucy.git
   2  script/plugin install git://github.com/toretore/babilu.git

Etape 2 : Ajouter Babilu a notre application

Il vous suffit alors simplement d’ajouter

   1  <head>
   2    <script type="text/javascript" src="/javascripts/locales.js"></script>
   3  </head>

dans l’en-tête de votre layout pour charger le fichier généré. Et d’utilisez directement

   1  I18n.t('string1') 
   2  I18n.t('messages.invalid', {scope:['activerecord', 'errors']})
   3  I18n.t('activerecord.errors.template.header', {count:2, model:'user'}) 
   4    // "2 erreurs empêchent la sauvegarde de User"

dans votre javascript.

Et voilà !

Le fichier javascript contenant les traductions est régénéré à chaque requête en développement et à chaque démarrage du serveur en production.

Pour plus de détails sur babilu :
http://github.com/toretore/babilu/tree/master

Un form_builder pour afficher les erreurs d'un champ autrement

Wed, 18 Mar 2009 00:00:00 +0000

Si vous avez déjà travaillé au développement de plusieurs applications Rails, il est possible qu’un jour, vous vous soyez dit : “J’en ai marre de cette tartine que me génère error_messages_for”.

A force de bidouille par-ci par là vous êtes parvenu à un résultat qui vous convenait. Mais comment afficher les erreurs d’un champ de manière élégante, par exemple, juste à côté du champ ? Le FormBuilder est votre ami !

On aimerait arriver à ce résultat là :

Créons notre Builder lib/error_form_builder.rb qui étend le FormBuilder de ‘base’

   1  class ErrorFormBuilder < ActionView::Helpers::FormBuilder
   2  end

Dans ce builder, on va surdéfinir les helpers pour les éléments d’un formulaire. Nous ne ferons le détail que pour le textfield, pour les autres éléments, il suffit de suivre le même exemple en analysant bien la structure de l’objet dans le FormBuilder de base.

C’est partit :

   1  def text_field(method, options = {})
   2        object = @template.instance_variable_get("@#{@object_name}")
   3        unless object.nil? || options[:hide_errors]
   4          errors = object.errors.on(method.to_sym)
   5          if errors
   6            text = " <span class=\"error\">
   7                #{errors.is_a?(Array) ? errors.first : errors}</span>"
   8          end
   9        end
  10        @template.text_field(@object_name, method, 
  11           objectify_options(options))+text.to_s
  12    end

La première chose que l’on fait dans ce nouveau helper text_field, c’est récupérer l’objet. Ensuite on vérifie s’il contient des erreurs relatives à la méthode que l’on passe en paramètre. Et si il y a des erreurs relatives à cette méthode, on vient concaténer un bloc span contenant le premier message d’erreur.

Un peu de css :

   1  span.error {
   2    color:#c30;
   3    float:left;
   4    display:block;
   5    font-size:1.1em;
   6    font-weight:bold;
   7    line-height:14px;
   8    text-align:left;
   9    padding:0px 0 0 5px;
  10    width:190px;
  11  }

Et voilà ! Une toute nouvelle manière d’ajouter les erreurs dans vos formulaires, et pour pas des masses d’effort ;)

Exporter ses données dans un tableur

Fri, 06 Mar 2009 00:00:00 +0000

Il arrive souvent que l’on aie besoin d’exporter un ensemble d’informations pour y accéder de manière plus conviviale dans un tableur.

Dans cet article, je vais vous montrer deux manières d’exporter un ensemble de données, ou plutôt deux formats différents pour cette exportation.

Partie 1 : Exporter en csv

Le premier format qui me vient à l’esprit quand on me parle de tableur, est bien évidemment le format csv (Comma Separated Values) qui, pour ceux qui ne le sauraient pas encore, sépare chaque valeur d’une colonne par une virgule.

La première chose à faire c’est d’installer la gem fastercsv.

   1  sudo gem install fastercsv

Puis d’installer le plugin to_csv d’Ary Djmal dans votre application.

   1  script/plugin install git://github.com/arydjmal/to_csv.git

La suite est encore plus simple. Pas besoin de ‘builder’, il suffit, dans le bloc respond_to de l’action de votre contrôleur et pour le format csv, d’appeler la méthode to_csv sur votre tableau de données, elle est pas belle la vie ? :-)

   1  class UsersController < ApplicationController
   2    def index
   3      @users = User.find(:all)
   4  
   5      respond_to do |format|
   6        format.html
   7        format.csv { send_data @users.to_csv }
   8      end
   9    end
  10  end

Il suffit alors d’ajouter dans votre vue un lien du style :

   1  <%= link_to "Exporter en csv", formatted_users_path(:format => :csv) %>

Et le tour est joué !

Partie 2 : Exporter en xls

Mais je vois déjà venir les mauvaises langues avec leurs gros sabots :

“Haaaa mais môôôsieur, le csv c’est bien beau mais mon Excel(lent) tableur préféré ne gère pas les caractères en UTF-8 dans un csv”

“Pas de bol”, vous dirais-je, mais pas de panique Ary a pensé à vous, pauvres utilisateurs de MS Excel.

Première étape, il nous faut ajouter ce nouveau type de fichier obscur dans notre initializer mime_types que vous trouverez à config/initializers/mime_types.rb

   1  Mime::Type.register "application/vnd.ms-excel", :xls

Et d’installer un second plugin, to_xls

   1  script/plugin install git://github.com/arydjmal/to_xls.git

Ouf ! Le plus dur est fait :-)

La suite est à peu de choses près exactement la même que pour to_csv, sauf qu’il s’agit maintenant de to_xls, donc, au risque de me répéter, elle est pas belle la vie ?

   1  class UsersController < ApplicationController
   2    def index
   3      @users = User.find(:all)
   4  
   5      respond_to do |format|
   6        format.html
   7        format.xls { send_data @users.to_xls }
   8      end
   9    end
  10  end

Il suffit alors d’ajouter un lien dans notre vue qui fait appel au bon format :

   1  <%= link_to "Exporter en xls", formatted_users_path(:format => :xls) %>

La méthode to_xls crée en fait un fichier XML lisible par Excel. Attention cependant, cela ne marchera que pour les versions d’Excel 2003 et plus.

Quelques liens de référence:

to_csv plugin: Better Excel compatibility

to_xls plugin: Export to Excel in Rails the easy way

Export to Excel in Rails 2

Recherche "Full text" avec xapian

Wed, 04 Mar 2009 00:00:00 +0000

Une recherche “Full text” devient souvent une nécessité lorsqu’on travaille sur des projets ayant beaucoup de contenu. Différents outils permettent de réaliser ce genre de recherches avec plus ou moins d’efficacité. Pour Rails, il existe bien évidement Ferret, probablement le plus connu, mais aussi Solr basé sur Lucene, Sphinx et enfin, Xapian.

Je n’ai pas la prétention de dire que je suis un expert en la matière mais ayant utilisé Xapian durant le dernier projet sur lequel j’ai travaillé, je me suis dit qu’un petit partage de connaissances s’imposait. Histoire de vous donner les moyens de tester tout ça par vous-même.

Etape 1 : Installer Xapian

Suivant votre OS il existe plusieurs manières d’installer Xapian. Tout est expliqué sur le site de Xapian. Choisissez la manière qui vous convient le mieux. Pour l’exemple on partira des fichiers source !

Télécharger les sources de xapian :
http://oligarchy.co.uk/xapian/1.0.10/xapian-core-1.0.10.tar.gz
Et les bindings qui nous permettrons de l’utiliser avec Ruby :
http://oligarchy.co.uk/xapian/1.0.10/xapian-bindings-1.0.10.tar.gz

Il est bien évidement conseillé d’utiliser la même version pour xapian et ses “bindings”.

   1  tar xvzf xapian-core-version.tar.gz
   2  tar xvzf xapian-bindings-version.tar.gz
   3  
   4  cd xapian-core-version
   5  ./configure
   6  make
   7  sudo make install
   8  
   9  cd xapian-bindings-version
  10  ./configure
  11  make
  12  sudo make install

Etape 2 : Installer acts_as_xapian

La première chose à faire est de récupérer acts_as_xapian sur github.

   1  script/plugin install git://github.com/frabcus/acts_as_xapian.git

Ensuite, d’exécuter les migrations associées.

   1  script/generate acts_as_xapian
   2  rake db:migrate

Voilà, nous sommes prêts !

Etape 3 : Tous dans le bac à sable

Dans tous les modèles ou vous souhaitez utiliser une recherche “Full text” ajoutez la ligne suivante :

   1  class Stuff < ActiveRecord:Base
   2   acts_as_xapian :texts => [:title, :description, :tags]
   3  end

En remplaçant, bien évidement :title, :description et :tags par les champs de votre modèle dans lesquels vous souhaitez faire la recherche.

Ajoutez quelques objets en db et construisez l’index de recherche en prenant soin de spécifier les modèles (séparés par un espace) pour lesquels il est nécessaire de construire cet index.

   1  rake xapian:build_index models="Stuff AutreModel1 AutreModel2"

On peut alors tester la recherche en console :

   1  rake xapian:query models=“Stuff AutreModel1 AutreModel2” query=“test”

Qui aura pour effet de rechercher “test” dans les champs renseignés dans le paramètre :texts de acts_as_xapian des trois modèles spécifiés.

Etape 4 : Et dans mon contrôleur ça donne quoi ?

C’est tout simple :

   1  @query = ActsAsXapian::Search.new([Stuff], @query_params)

On cherche dans le modèle Stuff avec pour paramètres de recherche @query_params (la chaîne de caractères que l’on veut rechercher).

Pour obtenir les résultats il suffit de faire :

   1  @results = @query.results

Attention ! @results n’est pas un tableau d’objets d’un modèle ActiveRecord ! Pour ça, il faut repasser le tout à la moulinette :

   1  @stuffs = @results.collect{|r| r[:model]}

Ou pour faire simple et en une seule ligne :

   1  @stuffs = ActsAsXapian::Search.new([Stuff], @query_params)
   2               .results.collect{|r| r[:model]}

Etape 5 : Et si mes données changent ?

Le seul petit problème d’acts_as_xapian est qu’il ne propose pas de mise à jour automatique de l’index lorsqu’il y a un changement dans les données. Si changement il y a, cette modification est ajoutée à la table acts_as_xapian_jobs que nous avons créée grâce à la migration de l’étape 2. Et ce n’est que lorsque l’on exécute

   1  rake xapian:update_index

que les changements sont pris en compte. Vous trouverez plus d’explications en suivant le premier lien à la fin de cet article. Qu’avons-nous fait dans notre dernier projet ? Une simple tâche cron, qui est appelée toutes les x minutes et qui met à jour l’index. Une autre qui s’exécute une fois par jour pour reconstruire complètement l’index.

Etape 6 : Et maintenant ?

Plusieurs autres possibilités sont présentes dans acts_as_xapian, comme la recherche par ‘terms’, ou encore la possibilité de proposer des corrections ou des alternatives à la recherche effectuée.

Notre introduction s’arrête malheureusement là, mais les quelques liens suivants vous serons sûrement très utiles :

Simple Ruby on Rails Full Text Search Using Xapian

The Xapian project

Mulling over our Ruby on Rails full text search options

Une application pas à pas - My Tag Cloud - épisode 3

Thu, 05 Feb 2009 00:00:00 +0000

Dans mon dernier article, nous avions passé en revue les éléments nécessaires à notre concept de ‘tag cloud’. Cette semaine, on replonge dans facebooker.

Au menu, mise en place d’une profile box et du Publisher qui va avec.

A l’image de Rails qui propose ActionMailer, une interface claire pour l’envoi d’emails, facebooker propose l’interface Publisher.

Dans ce Publisher, on peut définir des méthodes pour envoyer des notifications, des feeds, ou du contenu à une profile box.

Commençons par générer notre publisher.

   1  script/generate facebook_publisher facebook

Nous voilà maintenant avec un Publisher vide et les migrations qui vont avec, migrations qui nous seront utiles lorsque nous voudrons publier des feeds.

Commençons simplement par ajouter le helper de notre application à notre publisher.

   1  class FacebookPublisher < Facebooker::Rails::Publisher
   2    helper :application
   3  end

Ajoutons ensuite une méthode profile_update.

   1  def profile_update(user)
   2   send_as :profile
   3   recipients user
   4   profile "Testing..."
   5  end

Il suffit alors d’aller ajouter la ligne suivante dans le bas du layout de l’application

   1  <%= fb_add_profile_section %>

Qui a pour effet d’ajouter un bouton ‘Add to profile’. Lorsqu’on clique dessus, on voit apparaître une boîte de dialogue nous demandant notre accord.

Et voilà ce que ça donne dans l’onglet ‘Boîtes’ !

Comme vous le savez peut-être déjà, une profile box peut se placer à plusieurs endroits et avoir plusieurs tailles. Un onglet ‘Boîtes’ a été ajouté dans le nouveau profil, qui permet de stocker des ‘profile boxes’ de deux largeurs, 380 pixels pour les larges et 180 pixels pour les petites.

Mais cette boîte peut aussi être ajoutée à votre wall. La taille est, ici, encore différente, 250 pixels de hauteur maximum, la largeur étant également de 180 pixels.

Les tags FBML suivants permettent de définir un contenu spécifique pour chaque largeur.

   1  <fb:wide>
   2  <fb:narrow>

Dans notre exemple, nous ne différencierons pas les différentes tailles, étant donné que ce que nous devons afficher prend peu de place…

Nous pourrions définir le contenu de notre profile box directement après le mot clé “profile” dans notre méthode profile_update, mais un partiel semble plus approprié.

   1  def profile_update(user)
   2   send_as :profile
   3   recipients user
   4   @friend = Friend.find_by_facebook_id user.id
   5   profile render :partial => 'profile.fbml.erb', :locals => {:user => @friend}
   6  end

Nous envoyons au partiel les informations concernant l’utilisateur. De cette manière on pourra récupérer les tags dudit utilisateur dans le partiel.

Dans le dossier apps/views/facebook_publisher/ fraîchement créé, nous ajoutons notre partiel _profile.fbml.erb :

   1  <% if user.tag_list.empty? %>
   2   <p>No tags yet...</p>
   3  <% else %>
   4   <% tag_cloud user.tag_counts(:order => "name"), 
   5      %w(css1 css2 css3 css4) do |tag, css_class| %>
   6    <span class=<%= css_class %>><%= tag.name %></span>
   7   <% end %>
   8  <% end %>

Les pages de profils sont mises en cache par les serveurs de Facebook, il est donc nécessaire de forcer la mise à jour de contenu dans une profile box, d’où l’importance du Publisher. Nous devons donc, à un instant dans le processus d’utilisation de notre application, faire un “push” du contenu.

Il suffit alors de faire l’appel suivant lorsque quelqu’un vous a taggé ou lorsque vous taggez quelqu’un, en prenant soin bien sûr de donner en paramètre le bon utilisateur. Pour les besoins de l’article et pour voir un résultat directement nous allons placer cet appel dans notre contrôleur Friends, dans l’action show par exemple. Je rappelle que ce n’est que pour les besoins de cet article, dans ce cas la profile box ne sera mise à jour que lorsque l’utilisateur consultera son tag cloud dans l’application, ce qui n’a pas grand intérêt…

   1  FacebookPublisher.deliver_profile_update(@facebook_session.user)

Ce qui donne sur notre profil :

Et voilà le travail ! Dans le prochain article, nous nous attarderons sur les feeds.

Frailers.net passe à l'open source!

Tue, 03 Feb 2009 00:00:00 +0000

Après un an et demi d’activité sur Frailers.net, nous avons décidé de rendre son code source publiquement disponible sur GitHub. Nous en avons profité pour le remettre un peu au goût du jour. Vous trouverez tout ici:

http://github.com/belighted/frailers

Comme mentionné dans le README, quelques points forts du code:

basé sur Rails 2.3
utilisation du framework i18n de Rails pour le français
mise en évidence de la syntaxe dans le blog (via ultraviolet/oniguruma)
100% RESTful

Nous espérons que cela permettra aux débutants (et aux autres!) de voir comment fonctionne une application “réelle”, sachant que nous allons continuer à mettre le code à jour au fur et à mesure que de nouvelles fonctionnalités (et bugs ;-)) apparaîtront.

N’hésitez bien entendu pas à télécharger et commenter le code. Bon amusement!

Ruby on Rails Dev Room au FOSDEM '09 ce dimanche

Tue, 03 Feb 2009 00:00:00 +0000

Ce week-end se tiendra à Bruxelles le célèbre FOSDEM (Free and Open Source Software Developers’ European Meeting), un ensemble de conférences organisées chaque année autour du logiciel libre.

Comme l’an passé, une des “developer rooms” est consacrée le dimanche à Ruby on Rails et vos dévoués serviteurs y auront d’ailleurs l’occasion de faire 2 présentations (en english):

Jean-Baptiste, à 14h45, sur le thème Ruby and Java: What are the differences?
Nicolas, à 15h30, sur le thème Internationalization in Rails 2.2

Pour la liste complète des présentations, reportez vous à la page officielle.

Si vous comptez y être présent, n’hésitez pas à le signaler via Frailers sur notre page liée à l’événement: FOSDEM ’09 – RoR DevRoom … et bien sûr, passez nous dire bonjour!