Merci pour toutes ces précisions.
Pour répondre dans l'ordre :

- Pour le contexte c'est une question d'internationalisation.
J'ai des modeles liés à une table "lang" qui indique si tel record est
pour du "fr", "en" etc...
Pour ne pas avoir à réécrire tout mes find pour prendre en compte la
langue de l'utilisateur via I18n.locale, je voulais utiliser le
default_scope en lui passant la valeur de I18n.locale correspondant à
l'utilisateur.

- J'ai essayé de reprendre le hack de Rails 3, mais apparemment il y a
qd mm eu un certain nb de changement car après avoir réécris 3 méthode
j'ai toujours des problèmes... et comme c'est du hack de hack, je ne
suis pas très fan.

- Je vais voir ce que je peux faire avec ta méthode Renaud, cependant
je ne suis pas encore super à l'aise avec les scopes.

Sinon j'ai trouvé une "méthode" en mêlant default_scope et
named_scope, mais elle est très spécifique à mon cas sans être idéal.
Pour cela je set mon default_scope pour trouver que de "fr", et les
parties de mon application que je vais internationaliser (pas tout
pour commencer) je réécris mes find avec des named_scope qui seront
dynamique avec I18n et qui passeront par dessus le default_scope
défini.

En tout cas déjà grand merci pour vos proposition !


On 23 nov, 11:55, "Renaud (nel) Morvan" <[email protected]> wrote:
> 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]

Répondre à