begin   require "greg.rubyfr.net" rescue MacOSX, PostgreSQL, Ruby => e   RubyFR.read( "[Why not]" ) end

Les slides de la Keynote de DHH sont disponibles ici. Et voici le très intéressant commentaire de Nicolas Paton via la liste RubyFrance :

[...]

Pour ceux qui n’ont pas encore eux l’occasion de lire sa présentation, le fait n’est pas d’utiliser les méthodes HTTP POST, GET, PUT et DELETE pour appeler nos bonnes vieilles actions CRUD mais de créer de nouveaux modèles et contrôleurs (de diviser en fait nos gros modèles et contrôleurs) pour atteindre les données à modifier le plus directement possible (et de manière assez paradoxale car si l’on veut accéder le plus directement aux données on seraient tentés de faire des requêtes SQL directes alors que là on va pousser l’abstraction objet toujours plus loin avec la création de classes supplémentaires). Dit autrement il s’agit atteindre les attributs d’un modèle (brisé en de plus petits modèles joints à ce gros modèle) avec du CRUD direct grace à des jointures intelligentes. (Merde cette dernière phrase n’était pas claire)

Autrement dit (encore) : on se retrouve à la fin avec des contrôleurs et des modèles plus légers avec un minimum d’actions (uniquement CRUD si possible) et de methodes d’accés et de traitement des object et une lisibilité accrue.

On ne fait plus :

class Customer < ActiveRecord::Base
        has_many :addresses
end

class Address < ActiveRecord::Base
end

class CustomersController < ApplicationController
  def create_new_address # une méthode de plus dans le contrôleur customers…
    customer = Customer.find(params[:customer_id])
    customer.adresses.create(:street => ‘15, rue Lahire’, :city => ‘Paris’)
    customer.save
  end
end

Mais :

class Customer < ActiveRecord::Base
        has_many :addresses
end

class Address < ActiveRecord::Base
  belongs_to :customer
end

# on appelle le contrôleur qui gère les adresses
class AddressController < ApplicationController
  def create # on appelle une simple action create
    address = Address.create(
      :customer => params[:customer_id],
      :street => ‘15, rue Lahire’,
      :city => ‘Paris’
    )
    address.save
  end
end

Cool. Mais à quoi ça sert ??

À plusieurs choses. Bien que presque aucune ne soit exprimée dans les lignes de code dessus ; ce petit bout de code voulait juste montrer la structure de base du concept qui offre les avantages suivant :

• gérer les jointures dans leurs modèles et contrôleurs respectifs au lieux de passer par le contrôleur et le modèle parent
• ce qui permets limiter le nombre d’actions par contrôleur et de préférence n’avoir que du CRUD
• et de limiter la quantité de logique par modèle (traitement d’attributs, validation…)
• ce qui fait un code plus clair, plus facile à lire et maintenir
• ça nous pousse encore plus à créer des jointures N-vers-N intelligentes (has_many :through) dans lesquelles on gère la relation encore une fois en CRUD simple (voir diapo 21)
• ça rend l’utilisation de de respond_to encore plus aisée => on peut parler à différents client avec la même logique plus facilement (voir diapo 34 à 46)

Et là, c’est très cool.

Pas franchement de grandes nouveautés techniques dans cette partie de la présentation mais une bonne leçon méthodologique. DHH précise bien que ce n’est pas une obligation de programmer ainsi mais un objectif louable de vouloir programmer ainsi. Il propose ça comme une technique de design d’applications comme le sont les test. Et cette méthode ne s’applique évidement pas à tous les cas.

Désolé d’avoir exposé aussi maladroitement ce concept sur cette mailing-list ainsi. Mais l’idée derrière la présentation de DHH est très intéressante et on peut rapidement passer à côté. Et comme on a pas à attendre que la gestion de POST, GET, PUT, DELETE soit dans rails pour s’y mettre autant essayer ensemble de comprendre tout de suite la logique car l’air de rien, il s’agira (à mon humble avis) d’un des concepts phare de rails bientôt. C’est tellement pas bête et si simple. Pourvu que Ruby aille bientôt un peu plus vite aussi… (c’est pas pour bientôt parait-il…)

Après DHH a parlé de ActiveRecord mais là je n’ai rien compris. Les diapos ne sont pas évidantes. Quelqu’un aurait-il croisé une doc sympa là dessus ? Je n’ai pas encore regardé dans edge rails, voir s’il y avait quelque chose.

Aussi quelqu’un a-t-il saisi Acts_as_view (http://wota.jp/rk2006/) présenté par Maiha à RubyKaigi ? Il n’y aucune autre doc sur le web pour le moment (en français ou en anglais du moins) et je n’ai pas poussé la relecture pour tout comprendre…

Vive Ruby, Rails, ActiveJeSaisPasQuoi, CRUD et DHH président. Ou Sélectionneur de l’équipe de France… Motivation de l’équipe avant un match : Allez CRUD les gars ! Allez DRY ! Et pas But.create(:butteur => @butteur) mais Action.create(:but => true, :butteur=> @butteur, :passeur => @passeur, …) !