Mise à jour des options d'attachment_fu dans un model
Attachment_fu est un magnifique plugin rails à utiliser pour tout formulaire qui doit faire un upload de fichier. Je l'utilise ainsi dans mon projet pictrails. Au niveau du README d'attachment_fu, il faut appeler la méthode ActiveRecord#has_attachment dans le model pour configurer l'utilisation de ce plugin. J'ai voulu mettre à jour cette propriété à la volé dans pictrails. J'ai donc commencé à rappeler la méthode ActiveRecord#has_attachment en lui passant les paramètres qui ont changés. J'ai d'abord pensé que ça m'étais à jour les options en conservant les anciennes. Mais après quelques tests, j'ai constaté que ce n'était pas le cas. Si on voulait mettre à jour les propriétés d'attachment_fu par cette méthode, il fallait rappeler toute les options.
C'est alors qu'après une rapide investigation directement dans le code d'attachment_fu, j'ai constaté la présence de la variable attachment_options. Cette variable n'est en fait qu'un Hash reprenant tous les paramètre du model. En le modifiant, on pouvait donc conserver les anciennes options et modifier celle que l'on souhaite. Pour exemple, le commit c47be9d8590ea911f0c1fbd14401fef83e0081e6, fait la modification d'option avec attachment_options au lieu de has_attachment
[...]ProtectedAttributeAssignmentError lancé pour les attr_protected dans Rails 2.0
Il y a une semaine maintenant une évolution de rails a entraîné une modification qui peux empêcher les tests qui ont été réalisé avec Rails 1.2. Etant tombé dans le piège, je vais expliquer ici la modification qui a eu lieu.
Suite au ticket 9699, si vous utilisez la méthode attr_protected dans votre modèle, vous aurez dans votre environnement de Test une exception qui est lancé, ProtectedAttributeAssignementError, lorsque vous tentez d'assigner une des valeurs protégés par la méthode ActiveRecord::Base#attributes=.
En conséquence dans vos tests unitaires et surtout fonctionnels, il faut gérer ce cas. Deux techniques possibles :
- Utiliser assert_raise pour tester qu'une mauvaise assignation entraîne bien un exception.
- Utiliser la configuration de cette exception en indiquant dans votre test :
ActiveRecord::Base.whiny_protected_attributes = false
with_scope passé en protected dans Rails 2.0
Toujours en train de m'amuser à la migration de Redmine sur Rails 2.0, j'ai fait une nouvelle découverte sur les mises à jours de Rails 2.0. En effet, j'ai découvert que la méthode with_scope a été déplacé en "protected". Elle n'est donc plus accessible en public.
Cette modification a fait suite au ticket 8524 et a été mis à jours dans la révision 6909.
Bien sûr DHH a fait la remarque de cette modification dans son annonce sur la Release de Rails 2.0 PR.
Je vais vous faire une rapide traduction du passage concernant with_scope.
ActiveRecord::Base.with_scope a été déplacé en "protected" pour décourager son utilisation dans les controllers et en particulier dans les filtres. Désormais il est encouragé de l'utiliser uniquement dans le modèle lui-même. Ce pourquoi il a été initialement conçut et d'où il ne devrait pas sortir. Bien sûr, c'est tout ce qui concerne l'encouragement et le découragement. Si vous avez pesé le pour et les contres de l'utilisation de with_scope en dehors du modèle, vous pouvez toujours l'appeler de la manière suivante : .send(:with_scope)[...]
CookieStorage système par defaut de sauvegarde de session dans Rails 2.0
Je suis actuellement en train de tenter de faire la migration de Redmine vers Rails 2.0. Ça me permet de découvrir un peu Rails 2.0 et aussi de contribuer à ce projet que j'adore.
Durant cette migration, je suis tombé sur une exception que je ne comprenais pas :
CGI::Session::CookieStore::CookieOverflow (CGI::Session::CookieStore::CookieOverflow)
J'ai donc lancé une recherche pour comprendre pourquoi j'avais cette erreur. J'ai ainsi découvert que cette exception est dû à la taille de ma session. En effet, les sessions de redmine peuvent parfois être supérieures à 4Ko car elle englobe pas mal d'information. Hors il y a une limitation de cette taille de session à 4Ko. En faite cette limitation n'a lieu qu'avec les sessions enregistrés dans les Cookies. Hors ce nouveau système de stockage de session est une des améliorations de Rails 2.0 et il a été mis par défaut.
Pensez donc à changer ce mode de stockage de Session si vous avez de grosses sessions à stocker. Pour revenir à un mode de stockage par fichier vous pouvez mettre dans votre fichier environnement.rb :
config.action_controller.session_store = :PStore
Voici quelque lien intéressant traitant de ce sujet :
- What's New in Edge Rails: Cookie Based Sessions are the New Default (en)
- Révision intégrant le système de Session par Cookies
- Discussion sur la controverse lié à ce système de session (en)
Rails 2.0 erreur à éviter
Ayant annoncé la sortie de Rails 2.0 en PR, je me devais de tester cette version. Je l'ai donc fait immédiatement le soir.
Après un petit :
- rake rails:freeze:edge TAG=rel_2-0-0_PR
- rake rails:update
J'ai lancé mon serveur et là patatra. Erreur et serveur qui ne démarrais pas. J'avais l'erreur suivante :
# hello-21:44:11:~/programmation/ruby/rails/screeneur/trunk$ ./script/server # => Booting Mongrel (use 'script/server webrick' to force WEBrick) # => Rails application starting on http://0.0.0.0:3000 # => Call with -d to detach # => Ctrl-C to shutdown server # ** Starting Mongrel listening at 0.0.0.0:3000 # ** Starting Rails with development environment... # Exiting # /home/shingara/programmation/ruby/rails/screeneur/trunk/vendor/rails/railties/lib/commands/servers/mongrel.rb:16: warning: already initialized constant OPTIONS # /home/shingara/programmation/ruby/rails/screeneur/trunk/vendor/rails/railties/lib/commands/servers/mongrel.rb:19: undefined method `options' for []:Array (NoMethodError) # from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require' # from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `require' # from /home/shingara/programmation/ruby/rails/screeneur/trunk/vendor/rails/activesupport/lib/active_support/dependencies.rb:496:in `require' # from /home/shingara/programmation/ruby/rails/screeneur/trunk/vendor/rails/activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' # from /home/shingara/programmation/ruby/rails/screeneur/trunk/vendor/rails/activesupport/lib/active_support/dependencies.rb:496:in `require' # from /home/shingara/programmation/ruby/rails/screeneur/trunk/vendor/rails/railties/lib/commands/server.rb:39 # from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' # from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' # from ./script/server:3
J'ai ensuite tenté une autre technique. Installer le gem de Rails 2.0 PR :
gem install rails --source http://gems.rubyonrails.org
Là miracle tout fonctionnait normalement. Je ne comprenais pas pourquoi. J'enlève donc les gems installés, retente et même erreur.
J'ai donc lancé des recherches sur internet et auprès de personnes qui utilisaient Rails Edge, mais sans succès. J'ai donc fini par lancer la question sur la liste de discussion de Ruby On Rails Core (en). Très rapidement j'obtiens ainsi ma réponse.
En fait il s'agit d'ActiveResource qui a été supprimé et remplacé par ActionWebService. Ainsi les requires perdait un peu les pédales. Une des solutions pour résoudre ce problème est de mettre dans son environnement.rb une exclusion d'ActiveResource :
config.frameworks -= [ :active_resource ]
Par contre si vous utilisez cette méthode n'oubliez pas de le commenter pour l'enlever dans le futur.
[...]Rails 2.0 Preview Release est sortie
Ca y est Rails 2.0 est vraiment en cours de sortie. En effet hier, Rails 2.0 Preview Release a été taggé sur Subversion et une annonce officielle a été réalisée.
[...]
