constraints( ClientSubdomain ) do
    resource :organization, :only => %w( show edit update destroy ) do
      get 'close', :on => :member
    end
 
    root :to => 'static_page#get_page', :page => 'home_client'
  end
 
  constraints( AdminSubdomain ) do
    scope :module => 'admin' do
      resources :organizations
    end
 
    root :to => 'admin/organizations#index'
  end

So here, if I’m on the admin subdomain, I can handle multiple organizations, my clients ones. And if I am on a client subdomain, the organization resource is a singleton (client must only handle its own organization, right?).
Ok, let’s see what rake routes outputs.

close_organization GET    /organization/close(.:format)     {:action=>"close", :controller=>"organizations"}
 edit_organization GET    /organization/edit(.:format)      {:action=>"edit", :controller=>"organizations"}
      organization GET    /organization(.:format)           {:action=>"show", :controller=>"organizations"}
                   PUT    /organization(.:format)           {:action=>"update", :controller=>"organizations"}
                   DELETE /organization(.:format)           {:action=>"destroy", :controller=>"organizations"}
              root        /(.:format)                       {:action=>"get_page", :controller=>"static_page"}
     organizations GET    /organizations(.:format)          {:action=>"index", :controller=>"admin/organizations"}
                   POST   /organizations(.:format)          {:action=>"create", :controller=>"admin/organizations"}
  new_organization GET    /organizations/new(.:format)      {:action=>"new", :controller=>"admin/organizations"}
                   GET    /organizations/:id/edit(.:format) {:action=>"edit", :controller=>"admin/organizations"}
                   GET    /organizations/:id(.:format)      {:action=>"show", :controller=>"admin/organizations"}
                   PUT    /organizations/:id(.:format)      {:action=>"update", :controller=>"admin/organizations"}
                   DELETE /organizations/:id(.:format)      {:action=>"destroy", :controller=>"admin/organizations"}
              root        /(.:format)                       {:action=>"index", :controller=>"admin/organizations"}

Erf, not really helpful.

After playing a while with mapper, routeset and routes, I came to a solution.

Monkey patch for Constraints

First, we need to expose Constraints#constraints to the world. Create a lib/route_constraints.rb:

module ActionDispatch
  module Routing
    class Mapper
      class Constraints
        attr_reader :constraints
      end
    end
  end
end

Be sure to require it in config/environment.rb.

Rake task

Then, put this content in lib/tasks/route_with_constraints.rake:
Gist

namespace :routes do
  desc 'Print out all defined routes in match order, with names, per constraint class. Target specific constraint class with CONSTRAINT=x. Target specific controller with CONTROLLER=x.'
  task :constrained => :environment do
    Rails.application.reload_routes!
 
    constraints_routes = Hash.new
 
    Rails.application.routes.routes.each do |route|
      group = (route.app.class == ActionDispatch::Routing::Mapper::Constraints ? route.app.constraints.to_s : 'No constraint class')
      constraints_routes[group] ||= []
      constraints_routes[group] < < route
    end
 
    requested_constraint = ENV['CONSTRAINT']
 
    constraints_routes.each do |group, all_routes|
      if requested_constraint.nil? or group == requested_constraint
        puts "\n\nConstraint class : #{group}\n\n"
 
        if ENV['CONTROLLER']
          all_routes = all_routes.select{ |route| route.defaults[:controller] == ENV['CONTROLLER'] }
        end
 
        routes = all_routes.collect do |route|
 
          reqs = route.requirements.dup
          reqs[:to] = route.app unless route.app.class.name.to_s =~ /^ActionDispatch::Routing/
          reqs = reqs.empty? ? "" : reqs.inspect
 
          {:name => route.name.to_s, :verb => route.verb.to_s, :path => route.path, :reqs => reqs}
        end
 
        routes.reject! { |r| r[:path] =~ %r{/rails/info/properties} } # Skip the route if it's internal info route
 
        name_width = routes.map{ |r| r[:name].length }.max
        verb_width = routes.map{ |r| r[:verb].length }.max
        path_width = routes.map{ |r| r[:path].length }.max
 
        routes.each do |r|
          puts "#{r[:name].rjust(name_width)} #{r[:verb].ljust(verb_width)} #{r[:path].ljust(path_width)} #{r[:reqs]}"
        end
      end
    end
  end
end

Ok, now we have a rake routes:constrained task. Let see its output :

Constraint class : No constraint class

Constraint class : AdminSubdomain

   organizations GET    /organizations(.:format)          {:action=>"index", :controller=>"admin/organizations"}
                 POST   /organizations(.:format)          {:action=>"create", :controller=>"admin/organizations"}
new_organization GET    /organizations/new(.:format)      {:action=>"new", :controller=>"admin/organizations"}
                 GET    /organizations/:id/edit(.:format) {:action=>"edit", :controller=>"admin/organizations"}
                 GET    /organizations/:id(.:format)      {:action=>"show", :controller=>"admin/organizations"}
                 PUT    /organizations/:id(.:format)      {:action=>"update", :controller=>"admin/organizations"}
                 DELETE /organizations/:id(.:format)      {:action=>"destroy", :controller=>"admin/organizations"}
            root        /(.:format)                       {:action=>"index", :controller=>"admin/organizations"}

Constraint class : ClientSubdomain

close_organization GET    /organization/close(.:format) {:action=>"close", :controller=>"organizations"}
 edit_organization GET    /organization/edit(.:format)  {:action=>"edit", :controller=>"organizations"}
      organization GET    /organization(.:format)       {:action=>"show", :controller=>"organizations"}
                   PUT    /organization(.:format)       {:action=>"update", :controller=>"organizations"}
                   DELETE /organization(.:format)       {:action=>"destroy", :controller=>"organizations"}
              root        /(.:format)                   {:action=>"get_page", :controller=>"static_page"}

Way better :)

La passion enfin partagée

Internet offre d’incroyables possibilités de développement économiques. Tout un chacun a sa propre passion ou son propre produit « terroir » qui n’attend qu’une initiative pour atteindre le monde. L’import/export était quelque chose de relativement rare pour les particuliers avant l’émergence d’internet. Je me souviens encore avoir rêvé, étant enfant, de ces fabuleux jeux de super nintendo qui ne sortaient qu’au Japon et que je n’ai jamais pu m’offrir du simple fait que le coût de leur importation était exhorbitant. Aujourd’hui, j’achète des t-shirts rares aux États-unis pour le même prix que ce qu’on trouve dans des boutiques locales, comme H&M.

Je ne me ferais pas le défenseur du marché commun et de la mondialisation ; cependant le commerce via internet se montre particulièrement efficace (en terme d’offre et de coût) lorsqu’on recherche quelque chose de particulièrement rare et localisé : aujourd’hui, un vietnamien peut acheter une horloge comptoise au presque même prix que nous la trouverions chez nous.

En ces temps de chômage important, il y a ici une vraie opportunité : chacun peut mettre en place un commerce international sans avoir à avoir pignon sur rue dans chaque pays livré. Conséquence directe du changement d’échelle, nous pouvons concentrer notre activité sur un produit qui ne suffirait pas à nous faire vivre si nous étions restés sur l’échelle locale.

Le coût d’une boutique en ligne

Reste un problème majeur. Si créer une boutique en ligne à dimension internationale représente un coût ridicule par rapport à la même chose sans internet, il n’en reste pas moins que c’est très onéreux.

Le développement de la boutique elle-même représente en général entre 5000 et 10000 euros, selon la complexité. En cas de concurrence, le coup de référencement peut représenter 2000 à 5000 euros supplémentaires (cela dit, mieux vaut se lancer dans un projet sans concurrence web si on veut s’assurer de sa réussite).

Cela représente donc un investissement important, surtout pour une personne au chômage.

Kolibria à la rescousse

Mon ami Christophe Maximin de Kolibria vient de lancer un service web qui pourrait bien changer la donne.

Ce service s’appelle Zookshop, et ne propose ni plus ni moins que de créer une boutique en ligne pour à partir de 19euros par mois, ce qui représente ce que coûte habituellement le seul hébergement d’une boutique.

Concrètement, cela veut dire qu’aujourd’hui, n’importe qui peut créer une entreprise individuelle (qui permet de n’être imposé que sur son bénéfice réel), créer sa boutique pour 20euros, et commencer à vendre des produits.

La fin du développement classique?

Alors maintenant, nous autres développeurs, devons-nous nous dire que ce fumier de Christophe a pourri notre activité? :)

Personnellement, je dirais que non (bisou Christophe). Cela me fait penser aux services de création de site web, qu’ils soient moyens et gratuits (comme myspace) ou payants et bien faits (comme <insérez votre service préféré>). Il m’arrive régulièrement de me faire contacter par des personnes ayant un tel type de site, qui désire passer à une autre échelle en ayant un site totalement personnalisé. Et pourtant, ma clientèle de base est principalement faite de graphistes ou autres personnes du métier cherchant un développeur ; j’imagine que ces demandes sont encore plus fréquentes pour les personnes qui traitent directement les clients finaux.

Certes, Zookshop propose toutes les fonctionnalités standard qu’une personne attend de sa boutique web : gestion du catalogue, des factures, des zones de livraisons, des commandes, des bons de réductions, du blog, etc. Il est même possible d’embaucher un graphiste/intégrateur ou un seo et de leur faire refaire la structure des pages.

Cependant, il arrivera toujours (ou du moins : souvent) que la personne gérant une boutique qui commence a bien marcher veuille des fonctionnalités atypiques, qu’elle estimera appropriées aux produits qu’elle vend. Dans ce cas, il faudra bel et bien une boutique personnalisée, et les bénéfices déjà réaliser permettront d’envisager sa création sereinement.

Reste que ZookShop est une incroyable opportunité pour qui veut se lancer dans l’aventure du commerce en ligne sans ne disposer d’aucuns moyens, ou pour qui a des besoins très simples. C’est un type de clientèle qui n’aurait de toute façon trouvé personne pour réaliser sa boutique.

Un grand merci, donc, à Kolibria, pour l’évolution sociale qu’il a apporté :)

Voici donc la méthode que j’emploi pour faire du user acceptance testing. L’exemple décrit ici utilise rails, cucumber et rspec, mais cela fonctionne également bien avant Typolight, cucumber et phpspec.

Soit, je développe un site pour un client qui vend des peintures. Une des fonctionnalité est le catalogue de peinture. Pour compliquer un peu cet exemple (et le rendre donc plus proche de la réalité), disons que ce client veut que lorsqu’on visionne la page d’une peinture, on voit le nombre d’autres visiteurs qui la visionne en même temps. Je lui dis d’abord que cette fonctionnalité n’est pas rentable, si on prend en compte son temps/coût de développement et son retour sur investissement. Mon client m’assure que c’est rentable, grâce au principe « le monde attire le monde » : si un visiteur remarque que d’autres personnes regarde la peinture en même temps que lui, il aura plus envie de l’acheter.

Dans la user story du catalogue, on donc trouve le scénario suivant :

Scénario: Voir le détail d'une peinture
  Lorsque je vais sur la page de la liste des peinture
  Et que je suis le lien de la première peinture
  Alors je dois voir sa photo
  Et je dois voir son titre
  Et je dois voir son auteur
  Et je dois voir son prix
  Et je dois voir le nombre de personnes qui visualisent ce produit actuellement

Une fois que le client a validé ce scénario, j’écris les steps cucumber suivantes :

Then /je dois voir sa photo/ do
  response.should have_selector( '#paint .picture img[src*="paint-1-full.jpg"]' )
end
 
Then /je dois voir son titre/ do
  response.should have_selector( '#paint h1.title:contains("Paint 1 test")' )
end
 
Then /je dois voir son auteur/ do
  response.should have_selector( '#paint .author:contains("Paint 1 author")' )
end
 
Then /je dois voir son prix/ do
  response.should have_selector( '#paint .price:contains("10€")' )
end
 
Then /je dois voir le nombre de personnes qui visualisent ce produit actuellement/ do
  response.should have_selector( '#paint .viewer-count:contains("5")' )
end

Cucumber, couplé à webrat, a cet avantage de permettre de faire des tests précis des vues à base de sélecteur CSS3. De nombreuses autres méthodes sont permises, et notament toute une gamme de méthodes qui executent une action tout en la testant, par exemple .click_link( link ) fait une assertion sur l’existence de ce lien, puis le suit effectivement. Pour ma part, j’aime bien être le plus précis possible dans les sélecteurs dans mes steps afin de me permettre de composer d’un trait mes vues ensuite.

Ayant ces steps, je peux maintenant écrire ma vue :

<div id="paint">
  <h1 class="title">< %= @paint.title -%></h1>
 
  <div class="picture">
    <img src="<%= @paint.imageSRC -%/>" alt="Photo de < %= @paint.title -%>" />
  </div><!-- .picture -->
 
  <div class="author">
    < %= @paint.author -%>
  </div><!-- .author -->
 
  <div class="price">
    < %= "%.2f" % @paint.price -%>€
  </div><!-- .price -->
 
  <div class="viewer-count">
    < %= @viewer_count -%>
  </div><!-- .viewer-count -->
</div><!-- #paint -->

Je sais maintenant que mon controller doit assigner @paint et @viewer_count. J’ai également déjà de bon indices sur ce dont je vais avoir besoin dans mes modèles et ma base de donnée. Je peux maintenant écrire les test de mon controller. Qu’est-ce que ce controller doit faire? Il doit assigner un modèle Paint et calculer le nombre de personnes qui voient actuellement cet article. Réflichissant à cette deuxième fonctionnalité, je me dis que cela doit être une méthode de classe de Visitor, qui vérifiera les journaux de visite pour une page donnée. Je n’ai pas besoin d’en savoir plus pour l’instant.

require 'spec_helper'
 
describe PaintsController do
 
  def mock_paint(stubs={})
    @mock_paint ||= mock_model(Paint, stubs)
  end
 
  describe "GET show" do
    it "assigns the requested paint as @paint and the current viewers count as @viewer_count" do
      Paint.stub!( :find ).with( "1" ).and_return( mock_paint( :title => 'Paint 1 test', :imageSRC => 'paint-1-full.jpg', :author => 'Paint 1 author', :price => '10.0' ) )
      Visitor.stub!( :viewer_count ).with( '/paints/show/1' ).and_return( 5 )
      get :show, :id => "1"
      assigns[ :paint ].should equal( mock_paint )
      assigns[ :viewer_count ].should equal( 5 )
    end
  end
end

Je peux maintenant écrire mon controller.

class PaintsController < ApplicationController
  def show
    @paint        = Paint.find( params[:id] )
    @viewer_count = Visitor.viewer_count( request.request_uri )
 
    respond_to do |format|
      format.html # show.html.erb
      format.xml  { render :xml => @paint }
    end
  end
end

Désormais, je sais que j’ai besoin de deux modèles : Paint et Visitor. Je sais également à quoi ils doivent répondre : :title, :imageSRC, :author et :price pour les instances de Paint, :viewer_count pour la classe Visitor. Qu’est-ce qui sera attribut et qu’est-ce qui sera méthode dans tout cela? Je réalise maintenant que tous ce à quoi doit répondre une instance de paint est un attribut simple. Il s’agira donc d’un modèle simple avec title, imageSRC, author et price en tant que champs de la table `paints`.

À ce stade, je peux utiliser le generateur rspec_model pour créer ce modèle simple et ses tests :
./script/generate rspec_model Paint title:string imageSRC:string author:string price:float

Visitor est un modèle moins simple. Que sais-je sur lui? D’abord, il doit répondre à la méthode :viewer_count. J’écris donc tout de suite ce test.

require 'spec_helper'
 
describe Visitor do
  it "should give the viewer count" do
    Visitor.viewer_count( '/paints/show/1' ).should equal( 5 )
  end
end

Je m’interroge maintenant sur comment retrouver ce nombre. Les visites doivent être loggée dans une table. Un visiteur est considéré comment visitant une page s’il l’a visité dans les 5 précédentes minutes. J’identifie un visiteur par son IP. Je dois effacer les anciennes visites pour ne pas surcharger ma db. Ok, j’ai ce qu’il faut pour écrire mes specs.

D’abord, je sais que chaque visite doit être loggé. Cela passera donc par un before_filter dans application_controller.rb . Je modifie donc mon fichier de test de mon controller ainsi :

require 'spec_helper'
 
describe PaintsController do
 
  def mock_paint(stubs={})
    @mock_paint ||= mock_model(Paint, stubs)
  end
 
  before( :each ) do
    Visitor.stub!( :log )
  end
 
  describe "GET show" do
    it "assigns the requested paint as @paint and the current viewers count as @viewer_count" do
      Paint.stub!( :find ).with( "1" ).and_return( mock_paint( :title => 'Paint 1 test', :imageSRC => 'paint-1-full.jpg', :author => 'Paint 1 author', :price => '10.0' ) )
      Visitor.stub!( :viewer_count ).with( 'paints/show/1' ).and_return( 5 )
      get :show, :id => "1"
      assigns[ :paint ].should equal( mock_paint )
      assigns[ :viewer_count ].should equal( 5 )
    end
  end
end

Je peux maintenant écrire le before_filter :

class ApplicationController < ActionController::Base
  before_filter :log_visit
  helper :all # include all helpers, all the time
  protect_from_forgery # See ActionController::RequestForgeryProtection for details
 
  def log_visit
    Visitor.log( request.request_uri, request.ip, Time.now )
  end
end

Cela m’en dit plus sur mon modèle Visitor. Il possède une méthode de classe :log. Celle ci enregistrera l’ip, la page et la date. Cette méthode devra également être responsable du vidage de la table. Cela fait une requête de plus à chaque visite, mais ça maintiendra la table presque vide. Je peux donc écrire son test :

require 'spec_helper'
 
describe Visitor do
  it "should give the viewer count" do
    Visitor.viewer_count.should equal( 5 )
  end
 
  it "should log visits" do
    Visitor.should_receive( :delete_all )
    ip, page, date = '127.0.0.1', '/show/paint/1', Time.now
    Visitor.should_receive( :create ).with( :page => page, :ip => ip, :date => time )
    Visitor.log( page, id, date )
  end
end

Je sais maintenant que mon modèle ma table visitors possède les champs :page, :ip et :date. Je peux générer le modèle.
./script/generate model Visitor page:string ip:string date:datetime

Et je peux implémenter ma méthode :log

class Visitor < ActiveRecord::Base
  attr_accessible         :page, :ip, :date
 
  def self.log( page, ip, date )
    Visitor.delete_all( [ "date < ?", 5.minutes.ago.to_s( :db ) ] )
    Visitor.create( :page => page, :ip => ip, :date => date )
  end
end

Je sais également comment retrouver le nombre de visiteurs d’une page. Je complète donc son test :

require 'spec_helper'
 
describe Visitor do
  it "should give the viewer count" do
    page = '/paints/show/1'
    Visitor.should_receive( :all ).with( :conditions => [ "page = ?", page ] ).and_return( [ 1, 2, 3, 4, 5 ] )
    Visitor.viewer_count( page ).should equal( 5 )
  end
 
  it "should log visits" do
    Visitor.should_receive( :delete_all )
    ip, page, date = '127.0.0.1', '/show/paint/1', Time.now
    Visitor.should_receive( :create ).with( :page => page, :ip => ip, :date => time )
    Visitor.log( page, id, date )
  end
end

Et j’écris la méthode :

class Visitor < ActiveRecord::Base
  attr_accessible         :page, :ip, :date
 
  def self.log( page, ip, date )
    Visitor.delete_all( [ "date < ?", 5.minutes.ago.to_s( :db ) ] )
    Visitor.create( :page => page, :ip => ip, :date => date )
  end
 
  def self.viewer_count( page )
    return Visitor.all( :conditions => [ "page = ?", page ] ).length
  end
end

À ce point, j’ai terminé l’implémentation de mon scénario. Il ne me reste plus qu’à le tester. Les specs doivent déjà passer, Pour faire passer les tests de cucumber, je dois d’abord écrire ma route et inclure mes fixtures (nombreux sont ceux qui détestent les fixtures, aujourd’hui, je les trouve personnellement plus simple d’utilisation dans le cadre de cucumber).

L’immense avantage de cette méthode est de rendre tout évident. C’est un no-brainer total et il n’y a qu’à développer, au sens strict. Plutôt que de construire un outil en tentant d’imaginer ses usages, puis d’adapter les usages en fonction de l’outil créé ( schéma du type : on va des modèles aux vues ), je défini d’abord l’usage en disant ce que mes outils doivent faire, et je les construis en conséquence ( schéma du type : vues vers modèles ).

L’immense inconvénient est que les tests ne sont pas exécutables avant l’arrivée aux modèles. Il est donc important de procéder à très petite itérations. Celle que je viens de prendre pour exemple est déjà presque trop longue (en fait, il est assez probable qu’en situation réelle, j’aurai d’abord fait le :show classique, puis j’aurais rajouté le :view_count).

Prenons le script suivant :

class Person
  attr_accessor :food
 
  def initialize
    @food = 10
    @firstname = 'John'
    @lastname  = 'Doe'
  end
 
  def eat
    @food -= 1
    true
  end
 
  def name
    @firstname + ' ' + @lastname
  end
 
  def name=( fullname )
    parts      = fullname.split( ' ', 2 )
    @firstname = parts[0]
    @lastname  = parts[1]
  end
end
 
michel = Person.new
michel.name = 'Michel Dupont'
michel.food                     # => 10
michel.eat                      # => true
michel.name                     # => 'Michel Dupont'

Nous voyons ici qu’il n’est pas possible de distinguer, formellement, la méthode “eat” et la méthode “name” de l’attribut “food”. Que nous importe, finalement, leur implémentation? Lorsque j’utilise l’interface d’un objet, je veux soit exécuter une action, soit manipuler une valeur. Dans le cas où je souhaite retrouver une valeur, peu m’importe de savoir si cette valeur se trouve directement dans un attribut ou si une méthode est appelée pour me le retourner : cela relève de l’implémentation et non de l’usage. Au niveau de l’usage, ici, je sais que “food” et “name” me retourneront des valeurs, parce que ce sont des noms, et je sais que “eat” exécutera une action, parce que c’est un verbe.

Qu’en est-il en PHP? Le même script s’écrirait :

< ?php
class Person 
{
  public    $food;
  protected $firstname;
  protected $lastname;
 
  public function __construct()
  {
    $this->food       = 10;
    $this->firstname  = 'John';
    $this->lastname   = 'Doe';
  }
 
 
  public function eat()
  {
    $this->food -= 1;
    return true;
  }
 
 
  public function getName()
  {
    return $this->firstname . ' ' . $this->lastname;
  }
 
 
  public function setName( $fullname )
  {
    $parts = preg_split( '/ /', $fullname, 2 );
    $this->firstname = $parts[0];
    $this->lastname  = $parts[1];
    return $fullname;
  }
}
 
$michel = new Person();
$michel->setName( 'Michel Dupont' );   
$michel->food;                         // => 10
$michel->eat();                        // => true
$michel->getName();                    // => 'Michel Dupont'

Nous voyons ici que l’implémentation est clairement visible. “food” est un attribut, “eat”, “setName” et “getName” sont des méthodes. L’astuce, chez PHP, est de transformer un nom en verbe par l’emploi des setters et des getters ( setName() et getName() ) pour justifier l’appel d’une méthode. Néanmoins, rien ne justifie le fait que je doive exécuter une action sur une Person pour avoir son nom. Il s’agit d’une valeur et cela ne me regarde pas, à l’usage, de savoir comment ce nom a été retrouvé.

Suggestion d’une implémentation

Dans l’extension framework que j’ai faite pour Typolight, j’ai généralisé l’emploi d’un design différent pour répondre à ce problème. En voici un exemple :

< ?php
class Person 
{
  public    $food;
  protected $firstname;
  protected $lastname;
  protected $_cache      = array();
  protected $_uncachable = array();
 
 
  public function __construct()
  {
    $this->food       = 10;
    $this->firstname  = 'John';
    $this->lastname   = 'Doe';
  }
 
 
 
  /**
   * Check if a getter method exists
   *
   * @param string  the attribute name
   * @return mixed
   */
  public function __get( $key )
  {
    $firstLetter = substr( $key, 0, 1 );
    $rest        = substr( $key, 1 );
    $getter      = 'get' . strtoupper( $firstLetter ) . $rest;
 
    if ( method_exists( $this, $getter ) )
    {
      if ( array_key_exists( $key, $this->_cache ) and ! in_array( $key, $this->_uncachable ) )
      {
        return $this->_cache[ $key ];
      }
 
      $result = $this->$getter();
      if ( ! in_array( $key, $this->_uncachable ) )
      {
        $this->_cache[ $key ] = $result;
      }
 
      return $result;
    }
 
    throw new Exception( "Unknown attribute" );
  }
 
 
 
  /**
   * Check if a setter method exists
   *
   * @param string  the attribute name
   * @param string  the attribute value
   * @return mixed
   */
  public function __set( $key, $value )
  {
    $firstLetter  = substr( $key, 0, 1 );
    $rest         = substr( $key, 1 );
    $setter       = 'set' . strtoupper( $firstLetter ) . $rest;
 
    if ( method_exists( $this, $setter ) )
    {
      $this->_cache[ $key ] = $this->$setter( $value );
    }
 
    else
    {
      $getter = 'get' . strtoupper( $firstLetter ) . $rest;
      if ( method_exists( $this, $getter ) )
      {
        $this->_cache[ $key ] = $value;
        return true;
      }
    }
 
    throw new Exception( "Unknown attribute" );
  }
 
 
  public function eat()
  {
    $this->food -= 1;
    return true;
  }
 
 
  public function getName()
  {
    return $this->firstname . ' ' . $this->lastname;
  }
 
 
  public function setName( $fullname )
  {
    $parts = preg_split( '/ /', $fullname, 2 );
    $this->firstname = $parts[0];
    $this->lastname  = $parts[1];
    return true;
  }
}
 
 
// Nous pouvons maintenant faire ceci :
$michel = new Person();
$michel->name = 'Michel Dupont';  
$michel->food;                    // => 10
$michel->eat();                   // => true
$michel->name;                    // => 'Michel Dupont'

Ainsi, en utilisant les méthodes magiques __set() et __get(), nous pouvons rétablir le respect de la blackbox. Lorsque $michel->name est exécuté, __get() est appelé ( puisqu’il n’existe pas d’attribut $name ) et vérifie s’il existe une méthode getName().

En outre, cela permet d’ajouter un système de cache. La prochaine fois que j’appellerai $michel->name, la valeur précédente sera directement retournée plutôt que de devoir executer la méthode à nouveau. Si je veux éviter ce comportement, il me suffit d’appeler directement la méthode en faisant $michel->getName(), et le nom sera recalculé.

Bien entendu, mettre en place un tel mécanisme n’a pas de sens pour une petite classe isolée. J’ai employé personnellement ce mécanisme pour la couche modèle et la couche controller de mon extension. Cela est particulièrement intéressant pour les modèles, qui doivent se comporter de la manière la plus naturelle possible et qui font régulièrement des requêtes sur la base de donnée. Avec un tel mécanisme vous pouvez, dans le cadre d’un framework MVC, utiliser autant de fois que vous le voulez vos modèles dans vos vues de manière intuitive et sans vous soucier de savoir si cela va exécuter une requête sql ou non.

Le MVC, c’est quoi?

Pour ceux qui ne sont pas familiers à la notion de MVC, récapitulons brièvement. MVC est un acronyme pour : Model, View, Controller ( en français, ça marche bien aussi ). Il s’agit d’un design pattern qui structure une application selon trois tâches :

• Le traitement des données ( Modèles )
• La présentation des données ( Vues )
• La logique qui détermine quelles données associer à quelle présentation ( Contrôleurs )

Typiquement, dans une application web, les modèles sont tous les calculs faits sur la base de donnée ; les vues sont les fichiers contenant le html ( ou autre, par exemple la structure d’un email ) ; les contrôleurs sont ce qui gèrent les requêtes ( POST, GET, etc ), leurs paramètres, et décident quels modèles utiliser et quelles variables fournir aux vues.

La couche modèle est en général gérée par un ORM ( Object Relational Mapping ). Celui-ci permet de manipuler la base de donnée sans faire soi-même de pénibles requêtes SQL. Si par exemple j’ai dans ma base de donnée une table posts avec des champs id, name, content et author, j’aurai une classe Post, héritant de Model, qui me permettra de manipuler les entrées de la base de donnée comme des objets. Voici un exemple de PHP fictif qui illustre la manipulation d’un modèle :

// récupérer l'entrée de la tables posts qui à l'id 10
$post = Post::find( 10 );
 
// retrouver son attribut "name"
echo $post->name;
 
// le modifier
$post->name = 'an other name';
 
// sauvegarder le changement dans la base de donnée
$post->save();
 
// récupérer tous les posts dans un array
$posts = Post::findAll();

On peut ensuite utiliser ce array dans une vue, avec par exemple :

<ul id="posts">
  < ?php foreach ( $posts as $post ) : ?>
  <li><a href="post-<?php echo $post->id ?>">< ?php echo $post->name ?></a>, by < ?php echo $post->author ?></li>
  < ?php endforeach ?>
</ul>

Dans Typolight, les vues sont les templates et les contrôleurs sont les FrontendModule et BackendModule. Il n’y a malheureusement pas d’équivalence pour la couche modèle, et les données sont généralement retrouvées en remplissant les contrôleurs de requêtes SQL, ce qui rend la base de donnée pénible à utiliser et encombre les contrôleurs.

Comment utiliser une couche modèle dans Typolight?

Heureusement, une couche modèle existe belle et bien. Le fichier est TL_ROOT/system/libraries/Model.php . Ce fichier dispose des méthodes de base d’une couche modèle, mais il semble avoir été sabordé en route. En effet, c’est un singleton ( ce qui signifie qu’un seul objet de cette classe peut exister en même temps ). Il a en fait été pensé pour ne servir qu’aux classes User, BackendUser et FrontendUser, permettant de gérer l’utilisateur actuellement loggé.

Il n’y a en fait qu’une simple chose à faire pour rendre une couche modèle utilisable dans Typolight : créer une classe qui descend de Model et rendre publique sa méthode __construct(). C’est par exemple la méthode choisie par les développeurs de Isotope, ou par ma propre extension framework.

Nous allons reprendre la base du précédent tutoriel. Nous avions deux tables SQL : tl_filiere_services et tl_filiere_filiales. Nous allons donc faire deux classes de modèles : Service et Filiale.

< ?php if (!defined('TL_ROOT')) die('You can not access this file directly!');
 
/**
 * TYPOlight webCMS
 * Copyright (C) 2005 Leo Feyer
 *
 * This program is free software: you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation, either
 * version 2.1 of the License, or (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 * 
 * You should have received a copy of the GNU Lesser General Public
 * License along with this program. If not, please visit the Free
 * Software Foundation website at http://www.gnu.org/licenses/.
 *
 * PHP version 5
 * @copyright  
 * @author    
 * @package    
 * @license    
 * @filesource
 */
 
 
/**
 * Class Service
 *
 * @copyright  
 * @author     
 * @package    Model
 */
 
class Service extends Model
{
  protected $strTable = 'tl_filiere_services';
 
  public function __construct()
  {
    parent::__construct();
  }
}

< ?php if (!defined('TL_ROOT')) die('You can not access this file directly!');
 
/**
 * TYPOlight webCMS
 * Copyright (C) 2005 Leo Feyer
 *
 * This program is free software: you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation, either
 * version 2.1 of the License, or (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 * 
 * You should have received a copy of the GNU Lesser General Public
 * License along with this program. If not, please visit the Free
 * Software Foundation website at http://www.gnu.org/licenses/.
 *
 * PHP version 5
 * @copyright  
 * @author    
 * @package    
 * @license    
 * @filesource
 */
 
 
/**
 * Class Filiale
 *
 * @copyright  
 * @author     
 * @package    Model
 */
 
class Filiale extends Model
{
  protected $strTable = 'tl_filiere_services';
 
  public function __construct()
  {
    parent::__construct();
  }
}

Et c’est tout. Nous disposons maintenant de tout ce qu’il faut pour trouver une entrée, récupérer la valeur de ses champs, enregistrer ses changements ou l’effacer. Par exemple :

// crée un objet service
$service = new Service();
 
// retrouver l'entrée qui a l'id 10
$service->findBy( 'id, 10 );
 
// retrouve l'attribut 'name'
echo $service->name;
 
// modifie l'attribut 'name'
$service->name = 'new service';
 
// enregistre les modifications dans la base de donnée
$service->save();
 
// efface l'entrée
$service->delete();

Nous pouvons maintenant manipuler simplement nos services et nos filiales sans avoir à écrire de fastidieuses requêtes SQL.

Mais ce n’est pas tout ce à quoi sert un modèle. Pour respecter le design pattern, il faut que toute manipulation de donnée soit faite dans le modèle. C’est son rôle, après tout. Dans le monde de Ruby on Rails, il y a même une devise : “thick models, thin controllers” ( modèles gros et contrôleurs minces ). L’idée est que puisque les modèles gèrent les données et que, précisément, un site est d’abord une question de données, c’est aux modèles de faire la majeure partie du travail. Il y a là un partie pris ( comme toujours avec rails ), vous en penserez ce que vous voudrez. Néanmoins, il reste exact que les manipulations des données doivent être opérées par les modèles. Reste a définir la limite entre “traitement des données” et “contrôle d’une requête” :)

Prenons un exemple concret. Les services de nos filiales ont un prix. Disons que ce prix est hors taxe. Il va me falloir, à un moment ou un autre, calculer le prix TTC pour un service. C’est ici typiquement une méthode qui doit résider dans le modèle Service. Comme nous sommes insouciants, nous allons considérer que les taxes sont fixes et que nous pouvons considérer qu’elles sont de 20% ( dans un cas réel, il faudrait rendre cette valeur configurable en backend ). Voici la méthode que nous allons rajouter dans la classe Service :

public function ttc()
{
  $ttc = $this->price + ( $this->price * 0.2 );
  return $ttc;
}

Désormais, dans le template qui affiche un service, nous n’aurons plus qu’à faire :

<p>Prix TTC : < ?php echo $this->service->ttc() ?></p>

( nous verrons dans un prochain tutoriel comment passer des variables à un template ).

Ce que la classe Model de Typolight ne permet pas

Aujourd’hui, les ORM des frameworks permettent toutes sortes de raffinements, telle que les associations, les validations, finders et autres.

Nos filiales ont des services. Nous voudrions, avec un objet $filiale, pouvoir faire $filiale->services() pour avoir la liste des services de cette filiale. C’est ce que permettent de faire les associations, par le biais de relations ( has many, has one, belongs to, many to many… ).

Nous voudrions aussi empêcher d’enregistrer les modifications sur une filiale si l’adresse mail fournie n’est pas dans un format valide ( par exemple “1HD23s” ). C’est le rôle des validations ( elle sont présentes dans les widgets backend, dans Typolight, mais pas dans la couche modèle ).

Enfin, nous voudrions pouvoir, par exemple, trouver toutes les filiales enregistrées depuis moins d’un mois. Ou simplement trouver toutes les filiales. Ou trouver la première filiale qui se trouve à Lyon. C’est le rôle des finders.

Avec la couche modèle de Typolight, vous devrez écrire ces méthodes vous-même. Si vous désirez avoir une solution générique pour ces problèmes relativement courant, je vous invite à utiliser ma classe EModel : http://github.com/oelmekki/typolight_framework/blob/master/system/modules/framework/EModel.php ( promis, la documentation arrive. Vous devrez pour l’instant lire le code ou me poser des questions pour comprendre comment s’en servir ).

Cela conclut mon article sur les modèles dans Typolight. Nous verrons ensuite les modules frontend.

Pour rappel, ce même conseil avait rejeté une version précédente en faisant appel à l’article 11 de la déclaration des droits de l’homme de 1789, estimant qu’un filtrage du réseau nuisait à la liberté d’expression. En effet, Internet permet de communiquer et empêcher l’accès à Internet revient à nuire à la « libre communication des pensées et des opinions ».

Le point contesté était qu’une privation de liberté ne pouvait se faire sans l’intervention d’un juge (comme c’est le cas par exemple pour une peine de prison).

Or la loi que vient d’approuver aujourd’hui le conseil constitutionnel valide la mise en place de procédures simplifiées. Qu’est-ce qu’une procédure simplifiée? Ce n’est pas une comparution immédiate, telle qu’elle existe déjà dans les cas les plus extrêmes, c’est bien pire : il s’agit d’un jugement “interne” et immédiat dans lequel la présence de l’accusé n’est pas nécessaire.

Judge Dredd, bienvenue en France.

Notons cependant, ce passage du rapport des discussions :

M. Christian Paul. Quelle désinvolture, monsieur le Rapporteur, dans votre présentation des choses ! Nous sommes tout autant que vous garants de la qualité de la loi et de la défense des libertés !

Notre amendement vise donc à supprimer le recours aux ordonnances pénales. Vous nous dites, madame la ministre, que l’avis du Conseil d’État ne mentionne pas les ordonnances pénales. Je vous crois bien sûr. Mais n’est-il pas un peu facile de vous prévaloir de cet avis quand il vous arrange, tout en refusant de nous donner connaissance de l’ensemble du document ?

Monsieur le rapporteur, en acceptant une procédure de masse, vous réduisez les droits de la défense et proposez une justice expéditive. Cela n’est pas supportable. L’ordonnance pénale est une procédure écrite et non contradictoire : l’auteur des faits n’est pas entendu par le juge.

Mme Martine Billard. Même argumentaire.

M. le rapporteur. Avis défavorable. L’ordonnance pénale est certes une procédure simplifiée, mais elle est assortie de toutes les garanties. La personne incriminée peut être entendue par le juge si elle le souhaite et demander à être jugée au cours d’une audience publique.

La Commission rejette les deux amendements.

Ainsi, si vous êtes un jour victime d’Hadopi, sachez que vous pouvez refuser la « procédure simplifiée » et exiger un procès loyal.

Notons encore (tout de même) qu’il est bien habile de rejeter les soupçons de privation des droits fondamentaux sur les même juges qui subissent déjà des attaques en règle pour être assujettis au pouvoir exécutif, qui se met en même temps à l’écart des critiques constitutionnelles. Chapeau bas pour Machiavel.

J’ai réalisé ce site avec Telly Delalande, pour le compte de la société Stick’Innov. Telly s’est occupé de la charte graphique et de l’intégration et j’ai pris en charge le développement moteur et la couche javascript. Pour distinguer le site de ses concurents et lui offrir une avance en référencement, nous avons fait le choix de réaliser l’application sans utiliser flash, au profit d’une interface javascript non obstrusive et dégradable.

Le site est realisé entièrement sous Typolight, autant pour les pages statiques, que pour les fonctions motrices et que pour la partie boutique. Il constitue une première démonstration publique de ce qui est faisable avec Typolight et mon extension framework. Cette application étant commerciale et réalisée pour un tiers, je ne peux en montrer le code, mais je peux démontrer certaines particularités du framework.

Les routes

Ce qui est peut-être le plus flagrant pour un utilisateur de Typolight est l’usage des routes. Prenons par exemple l’adresse : http://www.stick-innov.fr/adhesif/Abstrait-35/modele/105.html . Ceci est rendu possible en utilisant une “route”. Une route est caractérisée par une définition, reflétant l’url, qui lorsqu’elle correspond renvoie à une page donnée avec des paramètres donnés. Ces routes peuvent être configurées soit dans le config/config.php de votre module, soit en backend. Ici, je l’ai mise dans le config.php, ce qui donne :

array_insert( $GLOBALS[ 'TL_ROUTES' ], 0, array(
    "fr_adhesif"          => array(
      'route'         => 'adhesif/:theme/modele/:modele_id',
      'staticParams'  => array(
        'action' => 'index',
        'type'   => 'adhesif',
      ),
      'method'    => 'GET',
      'resolveTo'     => 'adhesif',
    ),
  )
);

La définition de la route est donc ici : ‘adhesif/:theme/modele/:modele_id’. :theme et :modele_id sont des variables. N’importe quelle valeur peut y être introduite et sera injectée dans les paramètres GET, récupérable avec $this->Input->get( ‘nom_du_param’ ).

L’option ’staticParams’ permet de rajouter arbitrairement des paramètres supplémentaires. Ici, ‘action’ est utilisé pour déterminer quelle action le contrôleur devra executer et ‘type’ est un paramètre que j’ai ajouté pour pouvoir ne faire qu’un contrôleur pour les trois types de produits.

L’option ‘method’ détermine quel verbe http accepte la route. En utilisant GET, nous interdisons l’usage de POST. Si nous utilisons un POST sur cette url, l’application répondra par une 404. Cela permet de router vers des actions ou pages différentes le GET et le POST sur une même url. Les options de ‘method’ sont : ‘GET’, ‘POST’ ou ‘GET/POST’. Ce dernier accepte les deux verbes.

Enfin, l’option ‘resolveTo’ indique la page vers laquelle la route redirige.

Cette route a un nom : ‘fr_adhesif’. Ce nom est utilisé pour générer une url à partir d’un nom, grâce à Route::compose(). Ainsi, si nous avons :

array_insert( $GLOBALS[ 'TL_ROUTES' ], 0, array(
    "product_list"          => array(
      'route'         => 'voir/les/produits',
      'staticParams'  => array(
        'action' => 'list',
      ),
      'method'    => 'GET',
      'resolveTo'     => 'produits',
    ),
  )
);

et que nous voulons faire un lien en utilisant cette route dans une vue, nous pouvons faire :

<a href="&lt;?php echo Route::compose( 'product_list' ) ?&gt;">Voir les produits</a>

ou, avec un insert tag :

<a href="{{Route::product_list}}">Voir les produits</a>

Il est ensuite possible de modifier la définition de la route sans avoir à modifier ce code.

Dans le cas de la première route que j’ai montrée, il y a également deux paramètres dynamiques, :theme et :modele_id. Ces paramètres sont ajoutés en passant un array associatif :

<a href="&lt;?php echo Route::compose( 'fr_adhesif', array( 'theme' =&gt; $theme-&gt;urlName, 'modele_id' =&gt; $modele-&gt;id ) ) ?&gt;">Voir les produits</a>

Enfin, les routes supportent l’internationalisation. Si nous avons :

array_insert( $GLOBALS[ 'TL_ROUTES' ], 0, array(
    "fr_adhesif"          => array(
      'route'         => 'adhesif/:theme/modele/:modele_id',
      'staticParams'  => array(
        'action' => 'index',
        'type'   => 'adhesif',
      ),
      'method'    => 'GET',
      'resolveTo'     => 'adhesif',
    ),
    "en_adhesif"          => array(
      'route'         => 'adhesive/:theme/model/:modele_id',
      'staticParams'  => array(
        'action' => 'index',
        'type'   => 'adhesif',
      ),
      'method'    => 'GET',
      'resolveTo'     => 'adhesif',
    ),
  )
);

nous pouvons utiliser :

<a href="&lt;?php echo Route::composeI18n( 'adhesif', array( 'theme' =&gt; $theme-&gt;urlName, 'modele_id' =&gt; $modele-&gt;id ) ) ?&gt;">Voir les produits</a>

La langue courante sera utilisée pour déterminer quelle route il faut suivre.

Un dernier point : l’ordre des routes importe. Il est possible d’avoir des urls auxquelles plusieurs routes correspondent, comme par exemple si on a “voir/produits/tous” et “voir/produits/:produit_id”. Si cela arrive, la première route rencontrée l’emportera.

Les contrôleurs

Les contrôleurs de Typolight ( ModuleQuelqueChose, héritant de FrontendModule ) sont pensés pour n’executer qu’une seule action, bien qu’il soit possible de les forcer. Il y a la méthode generate() qui sert à initialiser le module, et la méthode compile() qui passe les variables à la vue ( template, dans le vocabulaire Typolight ). L’extension framework rajoute une nouvelle classe : RoutedModule.

RoutedModule est pensé pour permettre de gérer facilement des actions multiples. Quand un RoutedModule est généré, il regarde s’il existe un paramètre GET ‘action’. S’il y en a un et qu’une méthode du même nom existe dans le module, celle-ci est appelée et la vue est automatiquement déclarée selon le schémas : ‘fe’ + nom du contrôleur + ‘_’ + nom de l’action. Sinon, la méthode index() est utilisée. Prenons l’exemple d’un contrôleur simple :

< ?php
 
class ControllerProduct extends RoutedModule
{
  protected $controller = 'products';
 
  /* List products */
  protected function index()
  {
    $product = new Product();
    $this->Template->products = $product->all;
  }
 
  /* Show a product */
  protected function show()
  {
    $product = new Product( $this->Input->get( 'product_id' ) );
    $this->Template->product = $product;
  }
 
  /* Create a new product */
  protected function create()
  {
    $product = new Product();
    $success = false;
 
    if ( $posted = $this->Input->post( 'product' ) )
    {
      $product->data = $posted;
 
      if ( $product->save() )
      {
        $success = true;
      }
 
      else
      {
        $this->Template->errors = $product->errors;
      }
    }
 
    $this->Template->product = $product;
    $this->Template->success = $success;
  }
 
  /* Update a product */
  protected function update()
  {
    $product = new Product( $this->Input->get( 'product_id' ) );
    $success = false;
 
    if ( $posted = $this->Input->post( 'product' ) )
    {
      if ( $product->update_attributes( $posted ) )
      {
        $success = true;
      }
 
      else
      {
        $this->Template->errors = $product->errors;
      }
    }
 
    $this->Template->product = $product;
    $this->Template->success = $success;
  }
 
  /* Delete a product */
  protected function delete()
  {
    $product = new Product( $this->Input->get( 'product_id' ) );
 
    if ( $product->delete() )
    {
      $this->redirect( Route::compose( 'product_list' ) );
    }
  }
}

Ceux qui se sont déjà servi de Ruby on Rails trouveront ici une note familière. Un utilisateur de Typolight pourra s’interroger sur les méthodes de Product. Product hérite en fait d’une autre classe du framework, EModel, que je traiterai une autre fois.

La première chose à faire est de donner un nom au contrôleur :

protected $controller = 'products';

Ensuite, on définit les différentes actions, et le paramètre GET ‘action’ déterminera lequel utiliser. La vue est automatiquement retrouvée d’après le nom du contrôleur et de l’action, comme je l’ai expliqué plus haut. Ici, on aura donc les vues : fe_products_index.tpl, fe_products_show.tpl, fe_products_create.tpl, fe_products_update.tpl et fe_products_delete.tpl .

RoutedModule offre de nombreuses autres fonctionalités, comme la possibilité de forcer l’action sans prendre en compte le paramètre d’action ( utile lorsqu’on a plusieurs RoutedModule dans une même page ), les getters et les setters, le cache, la gestion de json, et autres.

Si vous désirez essayer l’extension framework, vous pouvez la télécharger sur github. Je suis sur le point de publier mon troisième site l’utilisant et je le considère donc comme stable. La version 1.0 devrait sortir sous peu, après un cleanup de l’API et l’écriture de documentation.

Premier contact avec Typolight

Lorsque j’ai commencé mes activités de freelance, j’ai rencontré Telly Delalande, avec lequel je travaille régulièrement aujourd’hui. Telly est passionné par un CMS qui s’appelle Typolight, et dont il m’a assuré que c’était le meilleur CMS du monde. Son article a provoqué de telles réactions que j’ai décidé de lancer un troll moi aussi :)

Plus sérieusement, quand Telly m’a parlé de Typolight, j’ai accepté d’y jeter un oeil sans trop y croire. Premier constat : la documentation pour développeur est franchement lacunaire. Ok, qu’à cela ne tienne, “use the source, Luke”. J’ouvre le code pour essayer de comprendre comment tout cela fonctionne. Et là survient la première surprise : c’est bien codé, très bien codé, même. Il y a bien quelques vieilleries PHP-iennes, comme l’absence d’une vraie classe modèle ( la classe Model est un singleton destiné à mapper l’user courant ) et donc la profusion de requêtes sql dans les contrôleurs, mais le tout est propre est agréable à lire (sauf quelques fichiers plus anciens que les autres).

Je décide donc de faire un essai, et de mettre l’extensibilité à l’épreuve.

Les modules

L’extension de Typolight se fait comme dans beaucoup de CMS par l’ajout de modules. C’est donc assez banal, mais ça m’a plu sur le coup comme je venais juste d’essayer Merb dont le concept de modulabilité m’avait beaucoup intéressé ( oui, ca se fait très bien par l’intermédiaire des plugins dans Rails ou Symfony, mais permettre quelque chose et encourager son utilisation dans le design même d’une application sont deux choses aux résultats totalement différents ).

Les modules de Typolight sont donc des répertoires, placés dans system/modules/, et dans lesquels on peut mettre tous les fichiers nécessaires à une fonctionalité : modèles, contrôleurs, vues, css, js, fichier de migration db, fichier de configuration, etc.

Tout de suite, les limitations apparaissent. Un contrôleur dans un module ne gère qu’une seule action. Cependant, l’application étant entièrement orientée objet et pensée pour la surcharge, il m’a été facile de rajouter un classe de contrôleur permettant de gérer plusieurs actions. Tout comme il m’a été possible de rajouter une gestion de routes complètement arbitraire. Tout comme il m’a été possible de rajouter un classe que j’ai nommée EModel, et qui reprend les fonctionnalités classiques d’un modèle dans les frameworks : associations, validations, recherches selon paramètres, etc. Les bases étaient posées.

Utiliser Typolight comme un framework

Au fur et à mesure que mes besoins se précisaient, je rajoutais des fonctionnalités dans mon module “framework” qui me permettait de développer d’autres modules sans sentir de contraites CMS-iennes. Chaque fois, j’étais surpris d’avec quelle facilité c’était faisable. Bien sûr, il faut parcourir le code et le connaître un minimum dans son ensemble pour se permettre des modifications aussi conséquentes, mais c’est chaque fois la même surprise : c’est possible, et proprement en plus.

Aujourd’hui, j’utilise Typolight d’une manière très similaire à mon utilisation de Ruby on Rails. J’ai intégré cucumber et phpspec par l’intermédiaire d’un module “testing“, je fais donc du bdd, à base de user stories suivant lesquelles je déroule mes vues, contrôleurs, modèles et routes dans un soucis de réutilisabilité.

Je me retrouve donc dans la situation où l’argument de manque d’extensibilité est brisé.

Focus!

Dans le même mouvement, je me retrouve avec une pluvalue d’avantages qui relève de tous les inconvénients du framework quand on le compare au CMS : pas de perte de temps à coder des fonctionnalités banales que je ferai de toutes façons moins complètes que celles présentes dans un CMS, développées depuis des années.

C’est là qu’apparaît le point vraiment intéressant : le fait de pouvoir se permettre de se focaliser entièrement et uniquement sur les fonctionnalités spécifiques dont a besoin le client. Cela rend le développement rapide, beaucoup plus rapide. Recoupé avec la possibilité de faire du bdd, cela permet de produire des applications complètes, stables et peu coûteuses.

CMS ou framework? Les deux mon capitaine.

Cela m’amène à me poser la question : en quoi les CMS et les frameworks sont incompatibles? Les développeurs condamnent régulièrement les CMS pour leur manque d’extensibilité, mais il ne s’agit pas là d’une fatalité. C’est simplement un fait courant. Pour ma part, je dirais que le problème est surtout que beaucoup de CMS ont une base largement impérative, avec des require partout, l’OO n’apparaissant que dans la couche intermédiaire de l’application.

Un CMS pensé proprement (la notion de propreté voulant surtout dénoter la conformité aux bonnes pratiques du jour) peut très bien être extensible et peut même être pensé comme un framework.

Je n’irai pas dire que Typolight est ce CMS de rêve, mais il s’en rapproche incroyablement plus que les CMS dont nous avons l’habitude. Il rend en tous cas concrètement possible la fusion entre CMS et framework.

Peut-être est-ce à nous, développeurs, de proposer aujourd’hui des solutions CMS/Framework qui garantissent à la fois la possibilité d’être utilisées par des non-développeurs, de mettre en place en quelques minutes les fonctionnalités courantes, et d’offrir une extensibilité complète.

L’idée est de permettre de définir des règles de conversion pour importer le contenu d’une base de données dans une autre.

Dans son utilisation la plus simple, vous pouvez définir un ensemble de règle traduisant une base de donnée dans une autre, par exemple pour changer de moteur de blog ou encore pour faire passer les données d’une application externe dans un module de CMS.

Il est également possible de s’en servir pour synchroniser une base de donnée. Si les entrées de la base de donnée source ont une clef primaire dont la valeur existe déjà dans la base de donnée de destination, les donnée de cette seconde base de donnée seront mis à jour (en suivant les règles définies).

Enfin, et c’est peut-être le plus intéressant, le framework peut être utilisé pour fusionner des bases de données. Imaginez que vous avez deux applications qui ont fait leur vie chacune de leur côté. Vous aimeriez importer les utilisateurs de l’une dans l’autre, mais il existe déjà des utilisateurs qui ont le même id. Datamith vous permet d’insérer ces utilisateurs tout en préservant les associations (par exemple le champs user_id de la table post).

Pour en savoir plus, je vous invite à voir la page de Datamith, ainsi que sa documentation. Le code est téléchargeable sur Github.

Cette tendance conseille de faire une distinction nette entre le javascript et le HTML (comme on distingue le CSS du HTML) et de ne voir en javascript qu’un “bonus”, ne perturbant pas l’utilisation du site si javascript venait à être désactivé par le navigateur.

Concrètement, cela passe par un développement de l’application excluant javascript, puis par l’implémentation d’une surcouche comportementale (animations, événements) dans un fichier javascript externe.

Il est donc exclu d’inclure de larges portions de javascript dans une balise script du HTML ou de définir dans les balises des attributs d’événements, comme onclick ou onmouseover.

Le problème

Si je veux exécuter la fonction name_clicked() lorsque je clique sur le li avec la classe name, je ferai ainsi avec jQuery :

$( 'li.name' ).click( function(){ name_clicked(); });

Le problème ici est que je ne disposerai d’aucun moyen pour savoir si l’événement à bien été attaché à un li en particulier. Si je clique sur le li et que rien ne se passe, est-ce un problème avec name_clicked() ou avec l’événement? Le seul moyen que j’ai de vérifier est de parsemer mon code de alert() ou de console.log(), ce qui est généralement la solution de dernier recours.

La solution

Ryan Taylor a publié au début du mois une extension pour firebug qui permet de lister les événements ajoutés à un élément du DOM : firebugUJS.

Son fonctionnement est simple : vous inspectez un élément comme d’habitude et vous choisissez dans la fenêtre de l’inspecteur de styles du menu HTML l’onglet Events. Le code du callback de l’événement y est alors présenté.

Limitations

L’extension est encore à ses débuts de développement. Elle ne supporte pour l’instant principalement que jQuery et LowPro (un effort pour rendre Prototype moins obstrusif).

Après une semaine d’essai, j’en suis relativement satisfait (relativement, parce que c’est donc un début et que je passe les problèmes pour cette raison). Cette extension m’a déjà permis de gagner du temps, mais il y a encore quelques petites choses à corriger. En particulier, les événements n’apparaissent parfois pas (il faut recharger la page une seconde fois), une quantité importante d’informations plus utiles au développeur de l’extension qu’à moi apparaissent dans la partie console de firebug (ce qui est tout à fait excusable) et surtout : il m’est déjà arrivé deux fois de devoir désactiver l’extension parce qu’elle faisait planter une application qui utilisait lourdement javascript (piwik la première fois, l’ajout d’image dans wordpress la seconde fois).

Malgré cela, je continue d’utiliser cette extension car je fais un usage intensif des événements js et qu’elle m’a déjà permis de gagner beaucoup de temps. Si ce n’est pas votre cas, vous voudrez probablement attendre une version plus stable.

Une affaire à suivre, donc :)