Bonjour tout le monde,
voilà mon problème
Je voudrais utiliser le plugin Globalize, jusque la pas de problème je
l’installe et tout se passe bien.
Mais maintenant je remarque, quand je joue avec mes migrations et mes
test
unitaires, que j’ai des conflits
J’ai dans mon appli rails un “model” Currency qui me permet donc de
stocker
les differents types de monnaie que va gérer mon application
Mais Globalize a également un model Currency
Les deux modèles se marchent sur les pieds.
Par exemple dans une de mes migrations j’ai:
Currency.delete_all
quand j’essaye de passer la migration j’ai l’erreur: undefined method
`delete_all’ for Globalize::Currency:Class (normal le currency de
globalize
n’hérite pas d’active record…)
de même quand je veux lancer mon test unitaire en faisant ruby
test/unit/currency_test.rb j’ai un charmant message qui
s’affiche: superclass mismatch for class Currency (TypeError)
le currency de globalize a pris la main sur mon “model”
Les migrations et les tests unitaires passaient sans problème avant
l’installation du plugin
pourtant j’ai regardé le code source du plugin, le “model” currency de
globalyze est bien définie a l’intérieur d’un module et donc d’un
namespace
spécifique (si j’ai bien compris)
La seule solution que je vois pour le moment est de renommer mon model
currency pour ne plus avoir de conflit de nom (réalisable car je suis au
début du développement de mon appli).
Mais je ne peux pas croire qu’il n’y ai pas une autre solution, ce
plugin
étant très connu, j’imagine mal
une limite pareille.
Quelqu’un a une idée?
Aurélien
“j’imagine mal une limite pareille”. Moi j’imagine mal de vouloir
écraser ce que propose un plugin. Donc bon, l’un dans l’autre…
Plus sérieusement, pourquoi ne pas te baser sur ce que te propose le
plugin ? En étendant si besoin est la classe proposée par le plugin.
++
yk
Le 07/07/07, Aurélien Bottazini[email protected] a écrit :
On 7/7/07, Yann KLIS [email protected] wrote:
“j’imagine mal une limite pareille”. Moi j’imagine mal de vouloir
écraser ce que propose un plugin. Donc bon, l’un dans l’autre…
Plus sérieusement, pourquoi ne pas te baser sur ce que te propose le
plugin ? En étendant si besoin est la classe proposée par le plugin.
je ne veux pas écraser ce que propose le plugin, il se trouve juste que
par
hasard une des classes du plugin a le même nom qu’une de mes classes.
Elle
ne sont pas du tout prévu pour faire la même chose.
Aurélien :
Je voudrais utiliser le plugin Globalize, jusque la pas de problème je
l’installe et tout se passe bien.
[…]
le currency de globalize a pris la main sur mon “model”
Les migrations et les tests unitaires passaient sans problème avant
l’installation du plugin
pourtant j’ai regardé le code source du plugin, le “model” currency
de globalyze est bien définie a l’intérieur d’un module et donc d’un
namespace spécifique (si j’ai bien compris)
À quoi correspond ta config de Globalize dans config/environment.rb ?
Si tu as un include Globalize, c’est normal que les constantes
de Globalize se retrouvent dans le “top-level namespace”.
– Jean-François, en direct des RMLL d’Amiens (un Tristan Nitot
vient de passer dans l’allée).
–
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
)