Bonjour à tous, Je compte proposer un atelier de refactoring lors du RailsCamp ce 17 mai. Au programme : - Allégement des contrôleurs - Structuration de l'application en REST (avec l'aide des namespaces) - Centralisation de la logique métier dans les contrôlleurs - Utilisation des Presenters pour DRYer les vues - Utilisation des Observers pour lancer des actions - etc... 1) Qu'en pensez-vous? 2) Je suis donc à la recherche de code à refactorer. Si certains courageux m'envoie leur code, je me ferai un plaisir de l'utiliser pour illustrer cet atelier. (Je cherche bien entendu du code qui ne respecte pas (toutes) les techniques décrites ci-dessus) Si d'autres ont des suggestions pour des sujets et techniques qui pourraient être présentées dans un tel atelier, vous pouvez me les transmettre (à l'avance ou durant l'atelier même). L'idée est bien que tout le monde participe et qu'un réel échange de connaissances se fasse. Bonne journée, Jean-Baptiste -- Jean-Baptiste Escoyez Belighted.com | Web 2.0 Consulting & Training Email : jbe@belighted.com | Phone: +32 486 377593
on 29.04.2008 09:37
on 29.04.2008 10:35
On 29 avr, 09:36, Jean-Baptiste Escoyez <jbesco...@gmail.com> wrote:
> - Centralisation de la logique métier dans les contrôlleurs
Tu voulais dire "dans les modèles" ;-)
Si non je suis très intéressé par ce sujet. Je démarre bientôt le
remaniement d'une application developpé avec la version 1.0 de Ruby on
Rails. Ce serait donc intéressant de comparer nos point de vue.
on 29.04.2008 13:24
Oups oui... Bien entendu :) On 29 Apr 2008, at 10:34, mourad hammiche wrote: > remaniement d'une application developpé avec la version 1.0 de Ruby on > Rails. Ce serait donc intéressant de comparer nos point de vue. > > -- Jean-Baptiste Escoyez Belighted.com | Web 2.0 Consulting & Training Email : jbe@belighted.com | Phone: +32 486 377593
on 29.04.2008 14:10
Je t'invite à fouiller là:http://www.refactormycode.com/codes/recent/ruby -- Baptiste
on 29.04.2008 18:21
Utilisation des Observers pour lancer des actions Perso, je ne pense pas que ce soit la meilleure maniere de d'approcher le probleme. Je prefere 100 fois utilisé tous les callbacks qui existent plutot que les Observers. En plus d'etre un gaspillage de mémoire les observers ne fonctionnent qu'avec ActiveRecord :( Sinon je trouve que l'atelier est une excellente idée, je suggererai peut etre d'aussi regarder les Conducteurs. -Matt
on 29.04.2008 18:43
On 29 Apr 2008, at 18:20, Matt Aimonetti wrote: > Perso, je ne pense pas que ce soit la meilleure maniere de d'approcher > le probleme. Je prefere 100 fois utilisé tous les callbacks qui > existent plutot que les Observers. En plus d'etre un gaspillage de > mémoire les observers ne fonctionnent qu'avec ActiveRecord :( Juste... Mais c'est aussi un bon moyen de garder le code bien propre. Je ne savais pas que c'était un gaspillage de la mémoire. Dans les cas où tu désires garder ton code séparé, que penses-tu de rassembler les callbacks relatifs dans un module et étendre les modèles avec ces derniers. Tu peux même imaginer utiliser le même observer pour plusieurs modèles (p.ex. un module "Logger" qui s'appliquerait à plusieurs modèles). > Sinon je trouve que l'atelier est une excellente idée, je suggererai > peut etre d'aussi regarder les Conducteurs. Bien que je ne les utilise pas encore. Je me pencherai sérieusement dessus pour le 17 mai. Merci pour les conseils, Jean-Baptiste -- Jean-Baptiste Escoyez Belighted.com | Web 2.0 Consulting & Training Email : jbe@belighted.com | Phone: +32 486 377593
on 29.04.2008 19:13
Il est vrai qu'un CallBack dans la plus part des cas plus simple. Mais l'utilisation d'un Callback n'est pas toujours judicieuse ou possible. Par exemple dans le cas où l'action à déclencher n'a rien à voir le modèle: Envoyer des messages de notifications, maintenir un journal d'audit etc. Peut-tu préciser en quoi l'utilisation d'un Observer gaspille de la mémoire ?
on 30.04.2008 00:53
Envoyer un message de notification peut être un contre exemple. En effet, ActionMailer ne connait pas l'environnement dans lequel il évolue a priori. Par exemple, si le mail en question doit contenir une URL en rapport avec le site, il est beaucoup plus facile et maintenable de construire l'objet ActionMailer dans un controller, et avoir accès au cycle normal de traitement de la requête, plutôtqu'écrire un observer qui impliquera toute une mécanique de gestion des URLs assez fastidieuse. ++ yk Le 29/04/08, mourad hammiche<mourad.hammiche@gmail.com> a écrit :
on 30.04.2008 02:58
Je suis d'accord avec avec Yann par rapport au contre-exemple du mailer. Quand je parle de gaspillage de mémoire, c'est un peu exagéré mais ca t'oblige a creer une instance d'un nouvel object qui en gros utilise de la "magie noir" pour creer des callbacks. Regarde le source: http://www.railsbrain.com/api/rails-2.0.2/doc/index.html?a=M001427&name=observers# Apparement, tu dois en plus declarer tous tes observeurs dans ton environment.rb : config.active_record.observers = :comment_observer, :signup_observer Tout ca pour quoi? juste pour mettre tes callbacks dans un autre fichier. Je te parie que la majorité des gens ne se rendent meme pas compte qu'un observeur n'est qu'un peu de metaprogramming pour creer des callback grace a un DSL. De plus, je suis partisant d'un code qui se lit facilement, et a moins que je me trompe, dans ton model il n'y a aucune references vers ton observeur. Si tu veux simplifier ton model, tu peux tres facilement utiliser un module avec tous les call backs et inclure ton module dans ton model. Moi, se prefere avoir tous mes callbacks dans mon model (les fonctions elles meme peuvent etre dans un module, ca ne me gene pas du tout). Ceci dit, il n'y a rien de grave avec l'utilisation des observers, c'est juste que c'est plus trop au gout du jour. -Matt