Bonjour,
Personnellement dans ce genre de cas ce que je faisais depuis Rails 1 est de
hacker directement via la méthode de classe ActiveRecord::scoped_methods
C'est concrètement un tableau qui fonctionne sous la forme d'un
class_inheritable_accessor, thread safe, qui contient le scope courant du
model. Name scope et default scope repose la dessus.
Il te suffit de créer une méthode de class ou d'instance pour configurer ce
scope sur ton modèle que tu appelleras dans un before_filter.
class Post < ActiveRecord::Base
class << self
def apply_language_scope(lang = :en_EN)
self.scoped_methods << {:find => {:conditions => {:lang
=> lang}, :create => {:lang => lang}}
end
end
end
Attention cependant, il faudra déconfigurer ton scope (avant de la reconfigurer
par exemple si il est toujours active, en around filter sinon, ne pas oublier
le ensure).
Il doit être possible de faire ce genre de hack via le initialize du modèle
mais globalement scoped_methods est une api stable depuis au moins 1.0, la
seule chose qui change c'est que suivant les versions elle devient
public/protected/private
Globalement c'est un hack de quelques lignes qui fait exactement ce que tu
souhaites mais c'est un peu touchy car ce ne sont pas des api publique en Rails
2.3, il faut bien comprendre les limitations et le fonctionnement interne des
scope en général pour gérer les effets de bords.
C'est le coeur du hack, tu peux lui donner une forme plus sympathique:
class Post < ActiveRecord::Base
class << self
def apply_language_scope(lang = :en_EN)
self.scoped_methods << {:find => {:conditions => {:lang
=> lang}, :create => {:lang => lang}}
end
def reset_language_scope
self.scoped_methods.clear
end
def with_language(lang = :en_EN)
self.apply_language_scope(lang)
yield
ensure
self.reset_language_scope
end
end
end
Et ton around filter se contente d'appeler with_language autour de l'execution
de la requête
R.
On 23 nov. 2010, at 11:22, guillaume wrote:
> Bonjour à tous,
>
> Je souhaite utiliser un default_scope, mais le rendre dynamique pour
> l'utiliser avec I18n.locale.
> La seule façon de faire à priori est de lui passer un Proc/Lambda....
> Malheureusement cela ne semble pas être supporté sous Rails 2, sous
> Rails 3 certains on patché (https://rails.lighthouseapp.com/projects/
> 8994/tickets/1812-default_scope-cant-take-procs) ActiveRecord pour le
> faire mais difficile de le reappliquer sous Rails 2 .
>
> Je ne veux pas faire de named_scope pour la simple et bonne raison que
> cela me ferai réécrire des centaines (voir milliers) d'appels, et
> passer sous Rails 3 c'est également trop de boulot pour l'instant.
>
> Je penche depuis pas mal d'heures sur ce problème, donc si vous avez
> des idées je grandement preneur,
>
> Merci.
>
> --
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
> Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
> [email protected]
> Pour résilier votre abonnement envoyez un e-mail à l'adresse
> [email protected]
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l'adresse
[email protected]
