Ce blog — désormais archivé — est en lecture seule. Rendez-vous sur mon nouveau site personnel.

Prendre un Café

L'espace d'expression de Nicolas Perriault

Aller au contenu | Aller au menu | Aller à la recherche

Keyword - framework

Fil des billets

jeudi 31 mai 2007

Google Gears : vous pouvez vous deconnecter

Note : ce billet est une reprise de l'article que j'ai publié sur le blog de Clever-Age, Google Gears : vous pouvez vous déconnecter.

Edit : Article publié sur ZDNet, la gloire ^^

Google a annoncé aujourd’hui à l’occasion du Google Developer Day le lancement de sa réponse technique concrète aux problèmes de la consultation et de la synchronisation de données web en mode déconnecté : Google Gears.

Cette réponse prend la forme d’une extension pour navigateur web (Firefox sur Windows, Mac et Linux, Internet Exporer sur Windows [1]) comprenant un serveur local, une base de données et un gestionnaire de transactions permettant de transformer le navigateur en solution client-serveur local afin de régler l’épineux problème du travail en mode déconnecté avec les applications web modernes.

En effet, si les applications en ligne se sont considérablement enrichies et sophistiquées ces dernières années, au point de devenir de plus en plus indispensables à certains d’entre nous, elles subissent cependant pour la plupart d’entre elles d’une limitation importante : la nécessité d’être en permanence connecté à internet pour fonctionner. Nombreux sont les cas d’impossibilité de se connecter au réseau des réseaux : zone de couverture, problèmes matériels, d’infrastructure, etc.

Bien sûr, certains se sont déjà - et parfois depuis longtemps - penchés sur la question. C’est le cas de Mozilla avec l’ajout dans la version 2 de Firefox d’une base de données SQLite ou du projet Zimbra permettant la sauvegarde de ressources locales. Mais l’une des solutions les plus avancées semblait se situer du côté du Dojo Offline Toolkit, un projet open source proposant des fonctionnalités de stockage d’interfaces, de données et d’applications en local et des fonctionnalités de synchronisation.

Google Gears se base sur cette dernière solution, embarquant le Dojo Offline Toolkit et une base de données SQLite au sein même de son extension. L’extension est open source (sous licence new BSD) et peut à ce titre être redistribuée dans une application embarquant le runtime ou utiliser une installation existante de l’extension. La disponibilité du code est également une bonne garantie quand à la transparence, au taux d’adoption, à la sécurité et l’évolutivité du produit [2]

Une des premières mises en oeuvre intéressantes de Gears se situe depuis ce matin dans Google Reader, l’agrégateur en ligne de Google : les utilisateurs ont pu remarquer la présence d’un nouveau bouton permettant de récupérer en local les 2000 derniers éléments non-lus afin de pouvoir les consulter hors-ligne.

Synchronisation de données en local dans Google Reader

Évidemment, ceci n’est qu’un début et Google ajoutera progressivement ce type de fonctionnalités à ses applications en ligne phares comme GMail, Calendar, Docs, etc...

Google Gears ne sera cependant pas limité au monde de Google, mais sera utilisable par tout éditeur de site Web concerné par ce type de problématiques. Imaginons par exemple l’application d’un constructeur automobile permettant de configurer son véhicule : l’utilisateur télécharge alors de façon transparente le catalogue des éléments disponibles et peut ensuite prendre tranquillement l’avion, utiliser l’application pendant le vol en configurant sa future voiture. Une fois rendu à destination, il synchronise sa simulation une fois reconnecté à internet et envoie les données au serveur web du constructeur.

Plus directement utile ? Le téléchargement en local des données cartographiques et des points d’intérêt de votre futur périple au bout du monde, hors-zone de couverture internet ? Vous y êtes ?

Alors, tout est au mieux dans le meilleur des mondes ? Peut-être pas, si l’on considère cette initiative de Google sous l’angle de la standardisation : en effet, Google et les équipes de développement Dojo proposent aujourd’hui une solution qui est basée sur un effort de réflexion qui a été initié auprès d’un nombre restreint de participants ; quid si demain Microsoft publie sa propre interprétation du problème ? Allons-nous à nouveau assister à un affrontement des deux géants, avec tout ce que cela implique en terme de problèmes d’interopérabilité ? Le fait qu’Adobe semble vouloir intégrer Gears dans Appolo et que Mozilla et Opéra soient de la partie risque de complexifier encore un peu plus le problème pour l’éditeur de Redmond.

Reste que le sujet est à surveiller de près, car les enjeux sont énormes à l’heure où les applications web tendent à empiéter de plus en plus sur le territoire des applications client-lourd traditionnelles.

[1] Le support de Safari et d’Opéra est d’ores et déjà annoncé.

[2] Déjà une mise à jour depuis le lancement ce matin même !

dimanche 29 avril 2007

Symfony, Admin-Generator et Composants

Dans un précédent billet, nous avons vu comment créer un weblog basique avec l'admin-generator de Symfony. Nous allons reprendre là où nous en étions et ajouter la liste des commentaires à notre back-office de gestion des billets grâce à un simple appel de composant, qui n'est autre qu'un template partiel associé à un contrôleur dédié.

Création du module de gestion des commentaires en back-office

Si ce n'est déjà fait, on crée notre module de gestion des commentaires

# symfony propel-init-admin back comments Comment

Création du composant qui va lister les commentaires d'un billet

Bien. On va maintenant créer un composant postcomments qui affichera la liste des commentaires associés à un objet Post, en créant un nouveau fichier apps/back/modules/posts/actions/components.class.php et en y insérent le contenu ci-dessous :

 php
<?php
class postsComponents extends sfComponents 
{
  
  /**
   * List comments for a given Post
   * 
   */
  public function executePostcomments()
  {
    $post_id = $this->getRequestParameter('id');
    if (!is_null($post_id))
    {
      $c = new Criteria();
      $c->add(CommentPeer::POST_ID, $post_id);
      $c->addDescendingOrderByColumn(CommentPeer::CREATED_AT);
      $this->comments = CommentPeer::doSelect($c);
    }
  }
  
}

On crée maintenant le template partiel associé au contrôleur, dans le fichier apps/back/modules/posts/templates/_postcomments.php :

 php
<?php if (isset($comments)): ?>
  <?php if (count($comments) > 0): ?>
    <?php use_helper('Comment', 'Text') ?>
    <dl>
    <?php foreach ($comments as $comment): ?>
      <dt>
        <?php echo sprintf('Posté le <strong>%s</strong> par <strong>%s</strong> :', 
                           format_date($comment->getCreatedAt(), 'd/MM/yyyy à H:m'),
                           format_comment_author($comment->getAuthor(),
                                                 $comment->getSite())) ?>
      </dt>
      <dd>
        <?php echo simple_format_text($comment->getContent()) ?>
      </dd>
      <dd>
        [<?php echo link_to('Éditer', 'comments/edit?id='.$comment->getId()) ?>]
        [<?php echo link_to('Supprimer', 
                            'comments/delete?id='.$comment->getId(),
                            'confirm=Êtes-vous sûr ?') ?>]
      </dd>
    <?php endforeach; ?>
    </dl>
  <?php else: ?>
    <p>No comment yet.</p>
  <?php endif; ?>
<?php endif; ?>

Utilisation d'un helper pour des tâches courantes de templating

La fonction format_comment_author est un helper maison, que nous définissons dans un nouveau fichier lib/helper/CommentHelper.php :

 php
<?php
/**
 * Returns a formatted html string for author including website link if any
 * 
 * @param  string   $name
 * @param  string   $site
 * @param  boolean  $nofollow
 * @return string 
 */
function format_comment_author($name, $site=null, $nofollow=true)
{
  if (!is_null($site) && preg_match('/^http/i', $site))
  {
    return sprintf('<a href="%s"%s>%s</a>', 
                   $site, 
                   $nofollow === true ? ' rel="nofollow"' : '',
                   $name);
  }
  else
  {
    return $name;
  }
}

Mise à jour du back-office de gestion des billets

Ceci fait, modifions le fichier de configuration du back-office d'administration des billets créé précemment et situé dans le fichier apps/back/modules/posts/config/generator.yml, afin d'appeller notre nouveau composant postcomments pour la vue d'édition d'un billet :

  [...]

    # Customisation du formulaire d'ajout/édition
    edit:
      
      [...]

      # Affichage d'une sélection de champs
      display:         [author_id, title, excerpt, body, post_sections, ~postcomments]

Vous noterez le caractère ~ précedant le nom du composant : encore une convention Symfony qui nous simplifie la vie :)

Gestion de l'échappement

Vous avez tous déjà entendu parler des failles XSS ? Pour nous en prémunir partiellement, nous allons activer l'échappement automatique des contenus passés à une vue, en ajoutant ces directives dans le fichier apps/back/config/settings.yml :

all:
  .settings:
    escaping_strategy: both
    escaping_method:   ESC_ENTITIES

Ainsi, dans notre cas toutes les chaînes seront échappées en entités HTML pour plus de sécurité. Pour plus d'information, rendez-vous dans la section dédiée de la documentation officielle.

Au final, voici ce que ça donne quand on édite un billet :

Affichage des commentaires d'un billet

Champs virtuels

Notre liste de billets, pour l'instant, ne nous informe pas pour chacun le nombre de commentaires associés. On va y remédier simplement en créant un getter ad-hoc dans notre objet de donnée Post et en appellant le champs virtuel associé. Dans le fichier lib/model/Post.php, on rajoute la méthode suivante :

 php
  public function getCommentsNumber()
  {
    return $this->countComments();
  }

Et dans le fichier apps/back/modules/posts/config/generator.yml, on affiche le champs virtuel comments_number dans la vue en liste :

  [...]

    # Customisation des colones de la vue en liste
    list:
      display:         [=title, excerpt, Author, comments_number, created_at, updated_at]

Voici ce que ça donne :

Liste des billets, avec nombre de commentaires associés

En conclusion

Voila, notre application prend forme doucement. On pourrait passez des heures à ajouter des détails par-ci par-là, mais je vous laisse le faire en compagnie de la documentation :)

samedi 28 avril 2007

Gagnez du temps avec Symfony 1.0 et son générateur de back-office

Lors du dernier petit-déjeuner Clever Age que j'ai animé sur les frameworks PHP, j'ai effectué une démonstration des fonctionnalités de génération de back-office existantes dans Symfony : la plupart des gens présents - pour la plupart découvrant la notion même de framework - ont été très impressionnés par la facilité déconcertante avec laquelle il était possible de développer une application complète en très peu de temps et d'étapes techniques grâce au générateur d'admin...

Personnellement, je suis tellement habitué à travailler avec de tels outils désormais que j'oublie parfois comme la vie est plus difficile sans eux... Je vais donc faire une démonstration afin que chacun puisse se faire son idée, sur sa propre machine :)

Pour faire très original, on va créer une petite application sommaire de gestion de weblog, doté des fonctionnalités suivantes :

  • Un auteur par billet
  • Billets multi-catégoriques (on pourrait aussi parler de tags)
  • Commentaires pour chaque billet

L'avantage est que la plupart des frameworks web proposent ce type de tutoriaux, donc ainsi vous pourrez plus aisément comparer :)

Installation de Symfony

Je vous renvoie à la documentation officielle ou à ce tutoriel pour installer Symfony sur votre machine et configurer un vhost apache pour votre nouveau projet. On partira sur la version 1.0.2, soit la dernière version stable disponible à l'heure où sont écrites ces quelques lignes.

Création d'un nouveau projet

Imaginons que votre projet soit créé dans /var/www :

$ sudo -s
# cd /var/www
# mkdir sftest && cd sftest
# symfony init-project sftest

Note: Si la page web par défaut du projet n'affiche pas d'images, il se peut que votre vhost ne trouve pas les éléments médias génériques de Symfony ; dans ce cas, un lien symbolique comme ci-dessous devrait régler le problème :

# ln -s /usr/share/php/data/symfony/web/sf web/sf

Note : Vous pourriez tout autant utiliser un alias apache dans votre vhost.

Créons maintenant nos deux applications front et back qui recevront le front-office et la console d'administration de notre projet :

# symfony init-app front 
# symfony init-app back

On crée une base de données dédiée au projet :

# mysql -uroot -p
> CREATE DATABASE sftest CHARACTER SET utf8 COLLATE utf8_general_ci;
> GRANT ALL ON sftest.* TO sftest@localhost IDENTIFIED BY '1234567'
> FLUSH PRIVILEGES;
> \q

Configuration de l'accès à la base de données

D'abord, on renseigne notre DSN MySQL dans le fichier config/databases.yml :

all:
  propel:
    class:          sfPropelDatabase
    param:
      dsn:          mysql://sftest:1234567@localhost/sftest

On fait la même chose pour Propel, dans le fichier config/propel.ini :

propel.database.url = mysql://sftest:1234567@localhost/sftest

Configuration du modèle de données

On crée le schéma de base notre de données, dans le fichier config/schema.yml :

propel:

  blog_authors:
    _attributes:    { phpName: Author }
    id: 
    name:           varchar(255)
    email:          varchar(255)

  blog_posts:
    _attributes:    { phpName: Post }
    id: 
    title:          varchar(255)
    excerpt:        longvarchar
    body:           longvarchar
    author_id:
    created_at:
    updated_at:
  
  blog_comments:
    _attributes:    { phpName: Comment }
    id: 
    post_id:
    author:         varchar(255)
    email:          varchar(255)
    site:           varchar(255)
    content:        longvarchar
    created_at:

  blog_sections:
    _attributes:    { phpName: Section }
    id: 
    name:           varchar(255)

  blog_posts_sections:
    _attributes:    { phpName: PostSection }
    id: 
    post_id:
    section_id:

Il y a beaucoup de magie dans la syntaxe de ce fichier. Retenez juste que les champs id, *_id et *_at sont nommés en vertus de conventions Symfony pour gérer automatiquement clés primaires, clés étrangères et les champs de type DATETIME.

Création d'un jeu de données de test

De même et parce qu'on est des gens sérieux (mais surtout parceque c'est pratique), on crée d'emblée un jeu de données de test (ou fixtures), dans un nouveau fichier data/fixtures/data.yml :

Author:
  NiKo:
    name:    NiKo
    email:   tepafou@fai.com

Post:
  FirstPost:
    title:   Mon premier post !
    excerpt: Un premier billet prometteur...
    body: >
      Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer 
      consectetuer congue diam. Sed eu enim. Cras fringilla, erat et pretium 
      tincidunt, elit nibh imperdiet lectus, vel viverra erat velit in  
      metus. Ut ipsum ante, ornare luctus, hendrerit in, ultricies id, est.
    author_id: NiKo
  
  SecondPost:
    title:   Mon deuxième billet
    excerpt: Un deuxième billet tout aussi savoureux.
    body: >
      Suspendisse potenti. Mauris id risus. Cras urna. Etiam vel enim nec 
      dui ultrices condimentum. Curabitur bibendum ultrices quam. Nulla 
      sodales risus eget nunc.
    author_id: NiKo

Section:
  Humeurs:
    name:    Humeurs
  Geek: 
    name:    Geek
  Ubuntu:
    name:    Ubuntu

PostSection:
  # First post categories
  FirstPost_Humeurs:
    post_id: FirstPost
    section_id: Humeurs
  FirstPost_Geek: 
    post_id: FirstPost
    section_id: Geek

  # Second post categories
  SecondPost_Geek:
    post_id: SecondPost
    section_id: Geek
  SecondPost_Geek: 
    post_id: SecondPost
    section_id: Ubuntu

Comment:
  Comment1:
    post_id: FirstPost
    author:  Jean-Paul
    email:   "jp@fai.com"
    site:    "http://blog.jeanpaul.com"
    content: Bravo, belle intervention.

  Comment2:
    post_id: SecondPost
    author:  Jean-Luc
    email:   "jl@fai.com"
    site:    "http://blog.jeanluc.org"
    content: Exactement, vous avez raison.

Ceci fait, on va lancer la génération du fichier SQL et des classes représentant notre modèle, créer les tables physiquement dans notre base et insérer notre jeu de données de test :

# symfony propel-build-all-load back

Vous noterez qu'un seule ligne de commande est à appeller, ce qui simplifie grandement les phases de prototypage.

Note : En cas de modification profonde du modèle de données, il est vivement conseillé de vider le cache symfony :

# symfony cc

Ajout des méthodes __toString() aux objets de données

Afin d'avoir facilement un descripteur texte pour notre objet Author, nous allons implémenter une méthode __toString() dans sa classe associée située dans le fichier lib/model/Author.php :

 php
class Author extends BaseAuthor
{
  public function __toString()
  {
    return $this->getName();
  }
}

Cette méthode retournera le contenu du champs name de l'enregistrement de la table blog_authors correspondant pour identifier l'objet PHP sous la forme d'une chaîne de caractère descriptive. Vous pouvez aussi adapter ce principe pour les objets Post et Section, par exemple.

Génération d'un back-office d'administration des billets

Maintenant, on va générer une interface d'administration de nos objets Post, accessible par un contrôleur /posts depuis notre application back :

# symfony propel-init-admin back posts Post

L'interface d'administration est maintenant accessible via /back_dev.php/posts derrière la racine de l'url de votre instance projet Symfony :-)

Administration des billets

C'est un peu sec par défaut et les sections associées aux billets du blog ne sont pas gérées, il nous faut donc adapter le fichier de configuration du générateur d'admin de Symfony pour ce module, situé dans le fichier apps/back/modules/posts/config/generator.yml :

generator:
  class:               sfPropelAdminGenerator
  param:
    model_class:       Post
    theme:             default

    # Customisation des colones de la vue en liste, lien d'édition sur le titre
    list:
      display:         [=title, excerpt, Author, created_at, updated_at]

    # Customisation du formulaire d'ajout/édition
    edit:
    
      # Champs personnalisés
      fields:
        # Création d'un champs d'administration des sections associées
        post_sections: { type: admin_check_list, params: through_class=PostSection }
    
      # Spécification des champs de formulaire à afficher
      display:         [author_id, title, excerpt, body, post_sections]

Un raffraîchissement des interfaces en mode développement (en appellant le contrôleur back_dev.php dans l'url) affichera nos interfaces modifiées en conséquences. Si vous utilisez le contrôleur de production (/back.php), n'oubliez pas de vider le cache symfony pour visualiser vos modifications :

# symfony cc

On reproduira exactement la même opération pour nos autres objets à administrer (Author, Comment et Section):

# symfony propel-init-admin back authors Author
# symfony propel-init-admin back sections Section
# symfony propel-init-admin back comments Comment

Voila, une vingtaine de minutes nous auront suffit pour générer une application en ligne relativement complète. Il restera à gérer notamment :

Amusez-vous bien :-)

mardi 6 mars 2007

Splitgames carbure au Symfony

La nouvelle version du site internet Splitgames, dont j'ai activement participé au développement et à la mise en place de la plateforme technique dans le cadre d'une mission Clever Age, est en ligne (avec un peu de retard, mais quand on aime, on ne compte pas.)

Splitgames est une plateforme d'échange en ligne de jeux vidéos. Cette nouvelle version, entièrement refactorée par rapport à la précédente, repose sur la version 1.0 du framework Symfony, dont je vous parle régulièrement ici même. Preuve s'il en est que de sympathiques choses peuvent être accomplies avec cet outil.

Félicitations à tout ceux qui ont travaillé sur le projet !

PS: Les popups javascript en rollover, c'est pas moi :p

samedi 3 mars 2007

Ruby on Rails 1.2.2, les migrations

Voici la suite du précédent tutoriel sur Ruby on Rails publié sur ce même blog ou nous avons mis en place une application de gestion de contacts rudimentaire.

Migration de schéma de base de données

Imaginons que nous voulions gérer une liste de sociétés, et lier chacun de nos contacts à sa société... Il va nous falloir modifier notre base de données en ajoutant une table companies et une clé company_id dans la table contacts. Cela peut s'avérer compliqué puisqu'elle contient déjà des données... même si en l'occurence il ne s'agit pour l'heure que de données de test.

Rails et plus particulièrement ActiveRecord proposent un outil de gestion des évolutions du modèle de données intelligent, les migrations. Au même titre que nous avions créé le fichier db/migrate/001_contacts_development.rb pour définir le schéma initial lors du tutoriel précédent, nous allons maintenant créer son évolution incrémentale dans le fichier db/migrate/002_contacts_development.rb :

 ruby
class ContactsDevelopment < ActiveRecord::Migration
  
  def self.up
    # On renomme le champs name en first_name (ne devra contenir que le prénom)
    rename_column :contacts, "name",       "first_name"
    
    # Ajout d'un champs pour stocker le nom de famille
    add_column    :contacts, "last_name",  :string
    
    # Ajout d'un champs pour stocker la société du contact
    add_column    :contacts, "company_id", :integer
    
    # Création de la table des sociétés
    create_table "companies", :force => true do |t| 
      t.column "name",        :string
      t.column "description", :text
      t.column "url",         :string
    end 
  end 

  def self.down
    # Rétablissement de la colonne name
    rename_column :contacts, "first_name", "name"

    # Destruction de la colonne last_name
    remove_column :contacts, :last_name
    
    # Destruction de la colonne contenant la référence à une société
    remove_column :contacts, :company
    
    # Destruction de la table contenant les sociétés
    drop_table :companies
  end 

end

Dans chaque classe de migration de schéma, une méthode up appliquera des modifications au modèles tandis qu'une méthode down permettra un rollback des modifications vers une version antérieure. Pour le détail des opérations effectuées par le script de migration ci-dessus, je crois que les commentaires parlent d'eux-mêmes ;) (j'en ai profité pour répartir le patronyme sur deux champs, nom et prénom)

La mise à jour effective du modèle dans la base de données s'effectue grâce à la commande :

 bash
$ rake db:migrate 
(in /home/niko/ww2/rails/contacts)
== ContactsDevelopment: migrating =============================================
-- rename_column(:contacts, "name", "first_name")
   -> 0.0750s
-- add_column(:contacts, "last_name", :string)
   -> 0.0153s
-- add_column(:contacts, "company_id", :integer)
   -> 0.0343s
-- create_table("companies", {:force=>true})
   -> 0.0304s
== ContactsDevelopment: migrated (0.1694s) ====================================

Nous n'avons pas d'outils d'administration pour notre nouvelle table companies, créons-les :

$ ruby script/generate scaffold Company

Il faut maintenant mettre à jour notre jeu de données ; on édite d'abord le nouveau fichier ./test/fixtures/companies.yml :

 yaml
Nanonical:
  id:          1
  name:        Nanonical
  description: On vous préfère libres
  url:         http://www.nanonical.com
  
Crimosoft:
  id:          2
  name:        Crimosoft
  description: Notre monopole, c'est trop lol
  url:         http://www.crimosoft.com

Toute ressemblance avec des sociétés existantes ou ayant existé serait un sacré coup de pot

Puis, dans le fichier ./test/fixtures/contacts.yml :

 yaml
John:
  id:         1
  first_name: John
  last_name:  Doe
  email:      john@doe.com
  address:    12, rue des champs
  zip:        75009
  city:       Paris
  country:    France
  company_id: 1 # John -> Nanonical
 
Bob:
  id:         2
  first_name: Bob 
  last_name:  Doe 
  email:      bob@doe.com
  address:    1, place du pré 
  zip:        35000
  city:       Rennes
  country:    France
  company_id: 2 # Bob -> Crimosoft

On réinsère nos nouvelles fixtures :

$ rake db:fixtures:load

On peut se rendre successivement aux adresses http://0.0.0.0:3000/contacts et http://0.0.0.0:3000/companies afin de s'assurer que tout va bien.

companies_scaffolding.png

Mise à jour des classes modèles

Pour que Rails prenne en compte les modifications structurelles de notre schéma, nous allons éditer les fichiers des modèles Contact et Company, notamment pour spécifier leur type de relation grace aux méthodes de classe ActiveRecord.

Le fichier ./apps/models/contact.rb :

 ruby
class Contact < ActiveRecord::Base
  # Chaque employé appartient à une compagnie
  belongs_to :company
end

Et le fichier ./apps/models/company.rb :

 ruby
class Company < ActiveRecord::Base
  # Une société possède plusieurs employés
  has_many :contact
end

Mise à jour du contrôleur

On récupère la liste des sociétés depuis le contrôleur gérant les contacts (situé dans le fichier ./app/controllers/contacts_controller.rb), d'abord pour la création :

 ruby
class ContactsController < ApplicationController
  [...]
  def new
    @contact = Contact.new
    @companies = Company.find_all
  end

Puis pour l'édition:

 ruby
class ContactsController < ApplicationController
  [...]
  def edit
    @contact = Contact.find(params[:id])
    @companies = Company.find_all
  end

Mise à jour de la vue

Enfin, modifions notre formulaire d'édition/création de contacts, situé dans app/views/contacts/_form.rhtml, comme suit :

 rhtml
<%= error_messages_for 'contact' %>

<!--[form:contact]-->
<p><label for="contact_company_id">Company</label>
<%= select 'contact', 'company_id', @companies.collect {|c| [c.name, c.id]} %></p>

<p><label for="contact_name">First name</label><br/>
<%= text_field 'contact', 'first_name'  %></p>

<p><label for="contact_name">Last name</label><br/>
<%= text_field 'contact', 'last_name'  %></p>

<p><label for="contact_email">Email</label><br/>
<%= text_field 'contact', 'email'  %></p>

<p><label for="contact_address">Address</label><br/>
<%= text_field 'contact', 'address'  %></p>

<p><label for="contact_city">City</label><br/>
<%= text_field 'contact', 'city'  %></p>

<p><label for="contact_zip">Zip</label><br/>
<%= text_field 'contact', 'zip'  %></p>

<p><label for="contact_country">Country</label><br/>
<%= text_field 'contact', 'country'  %></p>
<!--[eoform:contact]-->

Ce qui donne à peu-près ceci :

Nouveau formulaire de création/édition de contacts

Et le template d'affichage de notre liste de contacts, dans le fichier ./app/views/contacts/list.rhtml pour y ajouter la colonne affichant le nom de la société pour chaque contact :

 rhtml
<h1>Listing contacts</h1>

<table>
  <tr>
  <% for column in Contact.content_columns %>
    <th><%= column.human_name %></th>
  <% end %>
    <th>Société</th>
  </tr>
  
<% for contact in @contacts %>
  <tr>
  <% for column in Contact.content_columns %>
    <td><%=h contact.send(column.name) %></td>
  <% end %>
    <td><%= h contact.company.name %></td>
    <td><%= link_to 'Show', :action => 'show', :id => contact %></td>
    <td><%= link_to 'Edit', :action => 'edit', :id => contact %></td>
    <td><%= link_to 'Destroy', { :action => 'destroy', :id => contact }, :confirm => 'Are you sure?', :method => :post %></td>
  </tr>
<% end %>
</table>

<%= link_to 'Previous page', { :page => @contact_pages.current.previous } if @contact_pages.current.previous %>
<%= link_to 'Next page', { :page => @contact_pages.current.next } if @contact_pages.current.next %> 

<br />

<%= link_to 'New contact', :action => 'new' %>

Ce qui donne au final quelque chose comme ceci :

Nouvelle liste de contacts

To be continued

Dans un prochain tutoriel, nous aborderons la validation de formulaires.

samedi 3 mars 2007

Ruby on Rails 1.2.2, premier contact

Je dois préparer une réunion technique sur Ruby on Rails, aussi je m'y remets doucement. J'en profite donc pour passer en revue la version 1.2.2 du framework par le biais d'un petit tutoriel. Je prends pour exemple la gestion d'un carnet d'adresses simplissime.

Installation sur Ubuntu

L'installation de rails sur Ubuntu est toujours aussi simple.

Création de l'application

Vos pouvez créer votre projet rails n'importe où sur votre disque dur, par exemple dans ~/rails :

$ cd ~ && mkdir rails
$ rails contacts

Le squelette de l'application contacts est créé sous la forme d'un répertoire contenant l'arborescence par défaut d'un projet vierge.

$ cd contacts

Pour tester votre projet vierge, vous pouvez lancer Webrick, un petit serveur HTTP écrit en ruby inclus dans les librairies du framework :

$ script/server

Faites pointer votre navigateur à l'adresse http://0.0.0.0:3000/ pour admirer la page par défaut du projet.

Capture d'écran

Configuration de l'accès aux données

Dans le fichier config/databases.yml, on définit nos paramètres de connexion au SGBD, ici MySQL :

 yaml
development:
  adapter:  mysql
  database: contacts_development
  username: root
  password: password
  host:     localhost
  socket:   /var/run/mysqld/mysqld.sock

N'oubliez pas de créer une base MySQL contacts_development, hein ;)

Création d'une table dans la base données

On va utiliser le système de migration propre à rails pour garantir une évolutivité de notre modèle de données :

$ ruby script/generate migration contacts_development

On édite le fichier généré dans db/migrate/001_contacts_development.rb :

 ruby
class ContactsDevelopment < ActiveRecord::Migration

  def self.up
    create_table "contacts" do |t| 
      t.column "name", :string
      t.column "email", :string
      t.column "address", :string
      t.column "city", :string
      t.column "zip", :string
      t.column "country", :string
    end 
  end 

  def self.down
    drop_table :contacts
  end 

end

On lance la migration, ce qui pour l'heure aura pour conséquence et pour l'heure de créer notre table contacts dans la base de données :

$ rake db:migrate

Création d'un jeu de données

Nous allons créer quelques fixtures pour peupler notre table et avoir quelque chose à se mettre sous la dent. Pour cela, on crée (ou modifie) un fichier test/fixtures/contacts.yml contenant les deux entrées :

 yaml
John:
  name:    John Doe 
  email:   john@doe.com
  address: 12, rue des champs
  zip:     75009
  city:    Paris
  country: France

Bob:
  name:    Bob Doe 
  email:   bob@doe.com
  address: 1, place du pré 
  zip:     35000
  city:    Rennes
  country: France

On insère les données dans la base :

$ rake db:fixtures:load

Ces données permettront par la suite de tester plus facilement l'application.

Scaffolding

On crée un module basique de gestion de nos contacts :

$ ruby script/generate scaffold Contact

Faites pointer votre navigateur sur http://0.0.0.0:3000/contacts pour tester les scripts générés automatiquement.

Scaffolding basique dans rails 1.2.2

Ce n'est effectivement pas très beau, vous avez raison, mais c'est déjà fonctionnel... et surtout, cela ne nous a pas pris plus de 5 minutes !

À suivre

On ne s'arrêtera pas en si bon chemin, le prochain volet de ce tutoriel fera notamment évoluer notre schéma de base de données... stay tuned !

mardi 20 février 2007

Symfonique !

La version 1.0 stable du framework de développement PHP Symfony est sortie hier.

Cerise sur le gâteau, l'intégralité du livre officiel est également publiée sur le site. Croyez-moi, vous pouvez vous ruer dessus sans risque, c'est une énorme tuerie (et c'est un type qui entame son 5ème projet Symfony qui vous le dit !)

mercredi 7 février 2007

Créer un projet Symfony à partir des dépôts Subversion sous Ubuntu

Un des gros avantages du framework Symfony, c'est qu'il est régulièrement mis à jour. En ce sens, l'utilisation de liaisons externes Subversion permet de s'affranchir des opérations récurrentes de mise à jour manuelles du code du framework.

Seul prérequis pour mettre en oeuvre la technique décrite ci-après, avoir accès à un dépôt Subversion pour y stocker son propre projet personnel.

Voyons donc comment créer un projet Symfony from scratch à partir des sources du dépôt officiel, sous Ubuntu par exemple...

Conventions

Nous admettrons que nous avons mis en place un dépôt Subversion et que celui-ci est accessible à l'URL http://trac.mondomaine.tld/svn/monprojet.

Création du projet subversion

$ mkdir monprojet  && cd monprojet

On versionne notre projet nouvellement créé dans Subversion et on en fait un checkout en suivant :

$ echo "Mon projet README" > README
$ svn import -m "Initial import" . http://trac.mondomaine.tld/svn/monprojet
$ rm README && svn co http://trac.mondomaine.tld/svn/monprojet .

Liaison des sources de Symfony

On récupère le contenu intégral du trunk de Symfony dans un répertoire virtuel vendor/symfony, grâce à un svn:externals :

$ mkdir vendor && svn add vendor
$ svn propset svn:externals "symfony http://svn.symfony-project.com/trunk/" vendor

On commite :

$ svn commit -m "Added svn:externals to sf trunk in vendor/" vendor/

On oublie pas d'updater :

$ svn up

L'intégralité du trunk de Symfony est alors téléchargé en local (cela peut prendre un peu de temps).

Création du projet Symfony

Pour bien utiliser les capacités de Subversion par la suite, on créé un répertoire trunk dans lequel nous allons initialiser notre projet Symfony :

$ mkdir trunk && cd trunk
$ ../vendor/symfony/data/bin/symfony init-project monprojet

De même, on crée en même temps les traditionnels répertoires branches et tags :

$ cd ..
$ mkdir branches tags

Pour l'heure, un ls -l nous donne à la racine du projet subversion :

$ ls -l
total 20
drwxr-xr-x  2 niko niko 4096 2007-02-07 17:02 branches
-rw-r--r--  1 niko niko   95 2007-02-07 16:47 README
drwxr-xr-x  2 niko niko 4096 2007-02-07 17:02 tags
drwxr-xr-x 13 niko niko 4096 2007-02-07 16:59 trunk
drwxr-xr-x  4 niko niko 4096 2007-02-07 16:56 vendor

Configuration du projet Symfony

Il faut maintenant configurer le projet Symfony pour qu'il sâche trouver les librairies de base que nous avons précédemment récupéré - et surtout que le projet soit portable -, en éditant le fichier trunk/config/config.php :

$sf_symfony_lib_dir  = dirname(__FILE__).'/../../vendor/symfony/lib';
$sf_symfony_data_dir = dirname(__FILE__).'/../../vendor/symfony/data';

On teste l'installation en lançant la commande ./symfony -T depuis la racine du projet Symfony :

$ cd trunk
$ ./symfony -T

Si ça marche, on ajoute tout ce qui est nouveau fichier, et on commite en suivant :

$ cd ..
$ svn stat | grep ? | awk '{ print $2 }' | xargs svn add
$ svn commit -m "File structure created, sf project initialized" .

On pourra également faire un lien symbolique vers le répertoire web/sf, ou bien le définir en tant qu'alias dans le vhost apache :

<VirtualHost toto.monprojet.tld>
  (...)
  alias /sf /path/to/vendor/data/web/sf
  (...)
</VirtualHost>

Conclusion

L'avantage de toutes ces manipulations est que désormais, un svn up mettra à jour non seulement les fichiers de notre application, mais également le framework en lui-même. Les éternels grincheux crieront au loup quand au danger de lier une version de développement (trunk), je leur répondrai qu'un svn:externals peut tout aussi bien pointer vers une révision ou un tag particulier.

Par exemple, si vous désirez éviter de lier le trunk de Symfony, vous pouvez lier la version 1.0RC2 en spécifiant son url dans votre svn:externals :

$ svn propset svn:externals "symfony http://svn.symfony-project.com/tags/RELEASE_1_0_0_rc2/" vendor

Pour la suite, je vous renvoie à la documentation officielle de Symfony :-)

- page 2 de 4 -