Aller au menu - Aller au contenu

Découvrez Ruby on Rails dans sa version 3.0 !

Revenir à la liste des news
Participer à la discussion

Image

Informations

Contributeur(s) : Eregon et neowillow
Publié : le 03/09/2010 à 21:20:08
Catégorie : Programmation
Visualisations : 7 016

Licence : Creative Commons BY SA

Découvrez Ruby on Rails dans sa version 3.0 !

Image utilisateur

Après plusieurs bêtas, Ruby on Rails entre en version 3.0 finale. Cette toute nouvelle version débarque avec un lot de nouvelles fonctionnalités et d'innombrables corrections de bugs.

Ruby on Rails (ou RoR pour les intimes) est un framework web open-source écrit en Ruby par David Heinemeier Hansson et qui suit le modèle MVC. Son objectif est de rendre le développement web aisé, tout comme une grande variété de frameworks : Django (Python), Lift (Scala), etc.

RoR possède de bons atouts qui le caractérisent :
  • il permet de créer des sites web simplement et rapidement (voir la documentation sur developpez.com) ;
  • la flexibilité de Ruby lui permet de suivre DRY et ainsi d'avoir un résultat impressionnant et facilement maintenable pour un minimum de code ;
  • RoR offre également des technologies nativement intégrées comme la technologie AJAX permettant d’offrir aux utilisateurs une interface riche et ergonomique ;
  • la possibilité de créer un petit site web relativement complet grâce à de nombreux outils (générateurs de code principalement) déjà intégrés dans RoR.
Il peut donc en résulter des sites qui proposent des interfaces riches en fonctionnalités et pourvues d’une forte interactivité.


Les nouveautés de la version 3.0


Arel


Rails a choisi d'adopter le moteur de requêtes Arel pour Active Record, cette implémentation offrant la possibilité de faire des requêtes plus cohérentes et facilement composables. Elle permet aussi de retarder l’exécution de la requête jusqu'au moment où elle devient vraiment nécessaire.

En voici un exemple :

Code : Ruby
1
2
3
4
5
6
7
8
users = User.where(:name => "david").limit(20)
users = users.where("age > 29")

# SELECT * FROM users 
# WHERE name = "david" AND age > 29 
# ORDER BY name
# LIMIT 20
users.order(:name).each { |user| puts user.name } # La requête n'est exécutée qu'ici

Image utilisateur

Nouvelle interface pour les routes



L'interface pour définir les routes (quelle page est affichée pour quelle url et quels paramètres) a été repensée et a maintenant une syntaxe plus claire et relativement plus concise.

Toujours dans la syntaxe, on constate que cette version en apporte une qui privilégie le style d'architecture REST et qui offre également une plus grande flexibilité.

Code : Ruby
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
root :to => 'projects#index'

resources :people do
  resource :avatar
  collection do
    get :winners, :losers
  end
end

# /descriptions, /fr/descriptions, /en/descriptions
scope '(:locale)', :locale => /fr|en/ do
  resources :descriptions
end


Bundler


La gestion des dépendances d'une application Rails a longtemps été un soucis pour les développeurs. Pour résoudre ces problèmes, Bundler permet de spécifier l'environnement dans lequel s'exécute l'application.

L'installation est ainsi automatique et ne nécessite qu'un bundle install.
Bundler possède aussi des fonctionnalités avancées telles que la possibilité d'utiliser directement un projet sur Git (et donc de bénéficier des dernières mises à jour).

Voici un exemple de Gemfile :

Code : Ruby
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
source :rubygems

gem 'rails', '3.0.0'
# ou avec la version 'edge'
gem 'rails', :git => 'git://github.com/rails/rails.git'

gem 'mysql2'

group :development do
  gem 'capistrano'
end

group :test do
  gem 'rspec-rails', '>= 2.0.0.beta.19'
end


Au revoir les problèmes d'encodage !


La navigation sur Internet a souvent été rendue pénible du fait des problèmes d'encodage. Ceux-ci sont le plus souvent causés par le mélange d'informations sous différents modes d'encodage.

Avec une gestion native des encodages dans Ruby 1.9, Rails peut maintenant s'assurer de ne plus jamais assembler des données dans des encodages différents, et facilement les convertir au besoin.

Action Mailer


L'une des grandes nouveautés de cette version 3.0, c'est sûrement la réécriture de l'API ActionMailer. En bref, cette API permet d'envoyer des emails à partir de l'application web.

Auparavant, pour transmettre des emails, il fallait créer un modèle ActionMailer :

Code : Ruby
1
2
3
4
5
6
7
8
class UserMailer < ActionMailer::Base
  def welcome_email(user)
    recipients user.email
    from "I'm nobody <42@unknown>"
    subject "Hello World"
    body {:user => user }
  end
end


Avec Rails 3.0, c'est déjà plus simple grâce à l'intégration de la nouvelle bibliothèque Mail sur Action Mailer :

Code : Ruby
1
2
3
4
5
6
7
8
class UserMailer < ActionMailer::Base
  default :from => "I'm nobody <42@unknown>"
  def welcome_email(user)
    @user = user
    attachments['terms.pdf'] = File.read('/path/terms.pdf') 
    mail(:to => user.email, :subject => "Hello World")
  end
end


Sécurité


Image utilisateur
Internet est un environnement vaste et dangereux. C'est pourquoi, auparavant, RoR offrait une protection contre les attaques XSS assez complexe. Entre autres, il fallait échapper manuellement dans les vues les entrées de l'utilisateur avec des helpers.

Avec cette nouvelle version, il suffit maintenant de déclarer les entrées à ne pas échapper en les marquant comme html_safe. Ce qui est donc plus facile et privilégie la sécurité proposée par défaut.

Autres améliorations


Un certain nombre d'autres nouveautés sont arrivées dans cette version 3.0, vous pouvez consulter la liste des plus importantes sur l'annonce officielle de la sortie de Rails 3.0.


Liens utiles et sources


40 Participations

Pour accéder à cette section
Connectez-vous !
connexion_rpx
Page Précédente  1  2 
Pseudo Discussion
3 visiteurs sur cette news (0 membre et 3 anonymes)
Page Précédente  1  2 
Hors ligne neowillow # Posté le 04/09/2010 à 15:16:52
(/◔ ◡ ◔)/
Avatar
Groupe : Anciens

Citation : iPoulet
Je trouve l'exemple des e-mails assez amusant : on est (apparemment hein) passé d'un DSL super-hype (parce que Ruby c'est trop bien pour faire des DSL, à ce qu'il paraît) à une bibliothèque tout ce qu'il y a de plus classique comme tout le monde sait déjà faire.

Je pense que tu as tout à fait raison. :D Mais bon... si c'est plus simple, on ne va pas s'en plaindre.

#LGDF: victor vaincra !
« Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi »
Statistiques mondiales en temps réel. - FAQ C - The C LRG - FAQ Java - Python - OCaml - quoi.info - La France vue par différentes populations




 
Hors ligne gnomnain # Posté le 04/09/2010 à 15:21:22
Blblbl !
Avatar
Groupe : Anciens

Il faut dire que créer un DSL pour quelque chose d'aussi simple qu'envoyer un mail, c'est vraiment se compliquer la vie pour pas grand chose. Ça ne se justifie que pour des trucs un peu plus compliqués.

Image utilisateur
Haskell - Learn You a Haskell - Real World Haskell - xmonad - OCaml
Apprenez Haskell ! - #ircduzero
<colbseton> Serialk: tu cherches vraiment des liens logiques dans tout ce que je raconte ?
 
Hors ligne Eregon # Posté le 04/09/2010 à 18:17:42
Avatar

Ville : Ham-sur-heure
Pays : Belgique

Citation : gnomnain
Citation : Eregon

Non, c'est là tout l'intérêt des requêtes que j'ai dit "composables" (créées petit à petit et évaluées qu'à la fin, et non au sens mathématique du terme): ne faire qu'une seule requête, afin d'éviter des requêtes intermédiaires inutiles.

L'exemple d'utilisation de #limit n'est probablement pas le plus clair, mais en fait l'ordre dans lequel est appelé les méthodes ne doit rien changer au résultat. Cela permet donc d'appliquer des filtre successifs en mettant le #limit ou l'on veut (utile pour la pagination par exemple).


Mais cela oblige à voir les opérations comme des manipulations de requêtes, et pas comme des opérations sur des ensembles de données (qui ne sont pas en local sur la machine, mais on s'en fiche). Au lieu d'abstraire le SQL et tous ses côtés chiants, ça ne fait que bouger un peu la syntaxe. De plus, ça gêne la composabilité, parce que tu interprètes plutôt les requêtes données par les fonctions auxiliaires comme des ensembles de données.

Je pense que c'est une décision du design du fonctionnement de Arel. Je ne vois en pratique pas d'inconvénients majeurs à cette syntaxe. Mais bon, je ne connais pas bien les détails et donc je ne vais pas plus m'avancer sur le sujet.

Citation : Nami Doc
Arel est clairement ... Mis de côté. Vous montrez 1% de ce qu'il est capable de faire ...

Peut-être Nami Doc pourrait mieux en parler?

Citation : gnomnain

(Exemple : tu veux voir le nombre de personnes codant en Python dans le top10 de prologin. Pour cela, tu as une fonction top10 qui prépare la requête calculant ce top 10. Mais si tu écris top(10).where(:langage => "python") ET que top(10) utilise LIMIT (et par exemple, pas un WHERE sur un éventuel champ "classement), tu vas te retrouver avec les 10 meilleurs codeurs python. Tu deviens donc dépendant de la manière dont la requête originale a été codée, alors que ça ne devrait pas être le cas : à mon avis, les données renvoyées par la requête résultat des opérations appliquée à une requête originale ne devraient dépendre que des données que cette requête originale renvoie, et pas de son implémentation (seule les performances devraient pouvoir différer)

Tu peux toujours forcer à faire la requête intermédiaire (avec #all), et donc avoir des requêtes séparées comme tu veux.
Néanmoins, la 2è partie ne se ferait plus en SQL, mais directement sur les objets retirés
(par exemple: coders.select { coder.language == "python" } ).
J'imagine qu'il doit y avoir moyen de créer une requête comme tu veux, mais je ne connais pas assez Arel pour te dire ça.

Arel offre surtout une nouvelle syntaxe plus facile: ce screencast le montre bien.
Hors ligne bluestorm # Posté le 04/09/2010 à 18:50:11
dont ask to ask
Avatar
Groupe : Anciens
Flux RSS

Citation : Eregon
Arel offre surtout une nouvelle syntaxe plus facile: ce screencast le montre bien.


Une syntaxe plus facile... que ce qu'il y avait avant dans RoR. La syntaxe de Arel n'est pas plus agréable que la syntaxe du SQL, qui existe depuis des lustres et a fait ses preuves.

Il y a quelque chose que je trouve assez regrettable dans le monde des "cool kids" parmi les langages de scripts (Python et Ruby principalement), c'est qu'ils négligent totalement ce qui était fait avant eux, et qu'ils passent leur temps à réinventer des choses en disant à chaque fois que c'est beaucoup mieux qu'avant.

Par exemple quand on lit un changelog, on voit toujours une suite de "machin est mieux que truc !". Par contre, pour faire avouer que "truc n'était en fait pas terrible", il faut torturer les gens.

Je trouve ça un peu dommage parce que ça empêche d'avoir un point de vue large sur ce qui est fait. On vit au jour le jour, en essayant de se mettre à jour vers les dernières technologies à la mode (parce que si c'est nouveau, c'est sûrement mieux, même si à la prochaine version il faudra changer parce qu'en fait c'était pas si bien que ça).

Au contraire, dans des communautés qui sont plus proches du monde académique (je pense à Racket/PLT-Scheme, à Scala, ou même à une partie du travail sur .NET comme F# et SML.Net), les gens prennent le soin de comparer en profondeur les nouvelles choses avec qu'il y avait avant, et ont une attitude plus honnête des avantages et défauts des différents choix (même si on préfère toujours parler de ce qui marche plutôt que ce qui ne marche pas).
 
Hors ligne Eregon # Posté le 04/09/2010 à 19:23:44
Avatar

Ville : Ham-sur-heure
Pays : Belgique

Citation : iPoulet
Je trouve l'exemple des e-mails assez amusant : on est (apparemment hein) passé d'un DSL super-hype (parce que Ruby c'est trop bien pour faire des DSL, à ce qu'il paraît) à une bibliothèque tout ce qu'il y a de plus classique comme tout le monde sait déjà faire.

Pourquoi ? Les rockstars ont pris leur retraite ?

L'exemple dans la news n'est peut-être pas assez explicite.
Il y a un changement de syntaxe, et des effets hype genre trouver le sender dans une variable d'instance.
La plus grosse nouveauté est probablement exprimé dans cette ligne:
attachments['terms.pdf'] = File.read('/path/terms.pdf')
Ce qui crée un mail multipart, avec le bon mime_type et encoding et tout ;)
Donc ce n'est pas juste une bibliothèque "classique".

Je ne pense pas qu'on peut vraiment parler de DSL quand il n'y a que 4 méthodes.
Ce ne sont ici que de simple méthodes, rien de surprenant. Rien avoir avec RSpec, qui montre bien ce qu'est un DSL.
Hors ligne Eregon # Posté le 04/09/2010 à 20:01:22
Avatar

Ville : Ham-sur-heure
Pays : Belgique

Citation : bluestorm
Citation : Eregon
Arel offre surtout une nouvelle syntaxe plus facile: ce screencast le montre bien.


Une syntaxe plus facile... que ce qu'il y avait avant dans RoR. La syntaxe de Arel n'est pas plus agréable que la syntaxe du SQL, qui existe depuis des lustres et a fait ses preuves.

La news parle de Rails 3, donc oui, on compare principalement par rapport à la version précédente.

Utiliser Arel (ou tout moteur de requêtes) est beaucoup mieux que d'écrire son propre SQL, et la syntaxe est beaucoup plus claire de mon avis. Et puis, le SQL n'est pas universel, ni même toujours compatible entre les différentes bases de données.

Citation : bluestorm
Il y a quelque chose que je trouve assez regrettable dans le monde des "cool kids" parmi les langages de scripts (Python et Ruby principalement), c'est qu'ils négligent totalement ce qui était fait avant eux, et qu'ils passent leur temps à réinventer des choses en disant à chaque fois que c'est beaucoup mieux qu'avant.

Il faut bien créer des librairies pour les langages, et elles ne sont pas forcément géniales au début. La plupart des projets n'atteignent un niveau satisfaisant qu'après un certain temps.
Donc les améliorations sont logiques, donc on ne réinvente pas mais on applique au langage et parfois on recommence du début parce que ce n'est pas facilement applicable de réutiliser du code existant, ou tout simplement parce que l'auteur veut créer de son propre talent et ne pas "copier".

Citation : bluestorm
Par exemple quand on lit un changelog, on voit toujours une suite de "machin est mieux que truc !". Par contre, pour faire avouer que "truc n'était en fait pas terrible", il faut torturer les gens.

Tu entendras de qui tu veux que l'ancienne syntaxe n'était pas terrible (mais pas si mauvaise que ça). Néanmoins, tu ne trouveras pas dans les nouveautés ou un ChangeLog des critiques de l'ancien code, parce que ce n'est pas fait pour ça. Ce serait tout à fait inutile de critiquer comment c'était avant, il vaut mieux présenter ce qui est nouveau.

Citation : bluestorm
Je trouve ça un peu dommage parce que ça empêche d'avoir un point de vue large sur ce qui est fait. On vit au jour le jour, en essayant de se mettre à jour vers les dernières technologies à la mode (parce que si c'est nouveau, c'est sûrement mieux, même si à la prochaine version il faudra changer parce qu'en fait c'était pas si bien que ça).

Il y a une constante évolution, et donc si on souhaite utiliser du code récent et probablement amélioré par rapport au précédant, il faut se tenir à jour. Cela n'empêche pas d'avoir une vue plus large, même si tous ne se feront pas une large comparaison entre les versions.

Citation : bluestorm
Au contraire, dans des communautés qui sont plus proches du monde académique (je pense à Racket/PLT-Scheme, à Scala, ou même à une partie du travail sur .NET comme F# et SML.Net), les gens prennent le soin de comparer en profondeur les nouvelles choses avec qu'il y avait avant, et ont une attitude plus honnête des avantages et défauts des différents choix (même si on préfère toujours parler de ce qui marche plutôt que ce qui ne marche pas).

Tu me fais penser à Java. Et oui, les développeurs vont plus comparer les nouveautés avant de les utiliser. Ce qui fait que le développement de Java est très lent.
La communauté de Rails prends moins de temps à comparer, évaluer le pour et le contre, mais plus à créer (mais elle le fait quand même). Et comme chacun est libre de faire un "fork" ou de créer son propre gem, l'esprit est plutôt d'avoir plusieurs bibliothèques semblables, que de discuter longtemps pour avoir la probablement meilleure solution qui sera presque obsolète quand on pensera à la créer ...

Quand à l'attitude plus honnête, c'est hautement subjectif et chacun se fait son opinion, donc chacun fait son choix et utilise ce qui lui convient le mieux (au lieu d'attendre qu'une partie décide et l'utiliser bien plus tard).
Hors ligne Dentonia # Posté le 04/09/2010 à 21:13:21
Hermaphrodite psychopathe
Avatar

Citation : Eregon
Utiliser Arel (ou tout moteur de requêtes) est beaucoup mieux que d'écrire son propre SQL, et la syntaxe est beaucoup plus claire de mon avis. Et puis, le SQL n'est pas universel, ni même toujours compatible entre les différentes bases de données.


Bah, le principe du SQL, si, c'est quand même d'être universel. Qu'il soit plus ou moins bien implémenté, c'est un autre débat, qui n'est pas forcément résolu par un ORM qui va même, en général, restreindre à une liste de bdd bien connues.

Et dire qu'écrire en moteur de syntaxe, c'est beaucoup mieux, c'est parfaitement discutable. Perso, je préfère le faire, parceque ça me simplifie la vie, parceque ça rend les associations classiques (one-to-many, many-to-many) triviales là où il faut un peu réflechir en SQL. Mais j'irais pas jusqu'à dire que c'est inconditionnelement mieux. Surtout quand c'est pour écrire users.where au lieu de SELECT FROM users WHERE ...

Citation : Eregon
Ce qui fait que le développement de Java est très lent.
La communauté de Rails prends moins de temps à comparer, évaluer le pour et le contre, mais plus à créer (mais elle le fait quand même). Et comme chacun est libre de faire un "fork" ou de créer son propre gem, l'esprit est plutôt d'avoir plusieurs bibliothèques semblables, que de discuter longtemps pour avoir la probablement meilleure solution qui sera presque obsolète quand on pensera à la créer ...

En pratique, des forks de rails, yen a pas des masses, parceque c'est un projet trop lourd. Et dire que ça passe plus de temps à créer, c'est archi-subjectif. La communauté ruby (j'en fais partie, hein !) passe beaucoup plus de temps à dire qu'elle crée que les autres. Qu'elle crée réellement plus de choses qui aient une valeur que les autres, c'est plus dur à affirmer.

"I mean, it sounds like they're pretty skeptical. They'll think the talking dog was lying."
"Say that again."
"Say what again?"
"They're skeptical. They'll think the talking dog was lying."
 
Hors ligne bluestorm # Posté le 04/09/2010 à 23:12:18
dont ask to ask
Avatar
Groupe : Anciens
Flux RSS

Citation : Eregon
Tu entendras de qui tu veux que l'ancienne syntaxe n'était pas terrible (mais pas si mauvaise que ça).

D'accord, alors je pose la question : qu'est-ce qui n'est pas terrible dans Rails 3 ?

C'est aussi quelque chose que je trouve intéressant : comment les projets présentent leurs propres défauts.
 
Hors ligne Eregon # Posté le 05/09/2010 à 18:57:25
Avatar

Ville : Ham-sur-heure
Pays : Belgique

Citation : bluestorm
Citation : Eregon
Tu entendras de qui tu veux que l'ancienne syntaxe n'était pas terrible (mais pas si mauvaise que ça).

D'accord, alors je pose la question : qu'est-ce qui n'est pas terrible dans Rails 3 ?

C'est aussi quelque chose que je trouve intéressant : comment les projets présentent leurs propres défauts.

Ce qui me vient à l'esprit, c'est une certaine incohérence avec redirect_to/render, dans les options que l'on peut passer (le premier accepte :error => "message", l'autre nécessite :flash => { :error => "message" }).

Sinon je ne pense à rien de particulier, il faut un certain temps avant de voir là où sont les problèmes.
Et les projets préfèrent surement reconnaitre leurs défauts quand ils ont trouvé une solution ;)
Hors ligne Denzel Lockheart # Posté le 12/09/2010 à 21:37:24
Niveau 4 JLPT (190 *kanjis)
Avatar

Eh bien ça fait plaisir de voir que Ruby n'est pas un langage aussi oublié qu'un livre antique datant de 8000 ans avant Jésus-Christ brûlé pendant une guerre. ^^ Encore un petit effort et une news sur C# verra le jour ! :-°

J'ai vite testé Ruby on Rails et c'est pas mal ! On est pas obligé de taper 3000 lignes de code pour créer son application et quelques unes suffisent pour faire des sites web puissants et dynamiques.

Si jamais j'ai le temps, je saurais quoi faire ! :p
Pour accéder à cette section
Connectez-vous !
connexion_rpx

Revenir à la liste des news