Forum: Rails-ES Buenas prácticas: lookup hashes

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2009-04-16 13:03
(Received via mailing list)
Hola,

tengo un modelo con varios atributos que son escalas del tipo '0 => Mal,
1
=> Bien, 2 => Excelente'.  De las opciones disponibles: constantes en el
modelo, constantes en un archivo de configuración, lookup tables,
plugins
estilo "app config"
(http://www.google.com/search?q=AppConfig+plugin+rails)
.. ¿Cuál es vuestra preferida? ¿Recomendaciones a favor y en contra?

TIA!
1f2eadfb41362800ebc2cf211b91d0f7?d=identicon&s=25 javier ramirez (Guest)
on 2009-04-16 13:16
(Received via mailing list)
Hola,
> nibles: constantes en el modelo, constantes en un archivo de
> configuración, lookup tables, plugins estilo "app config"

yo sólo quería añadirte una opción más ;)

Si realmente en tus modelos usas las claves y las cadenas son pura
representación, y si además van a ser multi idioma, puedes crearte un
yaml propio para esto y utilizarlo con i18n directamente utilizando el
nivel como clave

tal que
---
es:
    rating:
       0: Mal
       1: Bien
       2: Excelente

---
y en las vistas

<%=t "rating.#{el_rating}"%>

Incluso si no van a ser multi-idioma te puede salir a cuenta usar algo
así para las claves maestras.. al fin y al cabo el i18n es estándar en
Rails y no tienes que andar con ficheros de configuración ad-hoc

saludos,


--
javier ramírez

..i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
..you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez
45742831d67c80d12cd7b24907b8d760?d=identicon&s=25 Sergio Gil Pérez de la Manga (Guest)
on 2009-04-16 13:22
(Received via mailing list)
Hola Manuel,

En el pasado he hecho cosas parecidas empleando una mezcla de
constantes en el modelo y unas gotitas de
metaprogramación:http://porras.lacoctelera.net/post/2008/01/13/un-t...

Más recientemente y en aras de usar la solución más simple posible +
evitar la optimización prematura, he hecho un poco lo mismo pero
usando directamente strings y validates_inclusion_of

Un saludo,

2009/4/16 Manuel González Noriega <manuel.gonzalez.noriega@gmail.com>:
> --
> Manuel,
> http://simplelogica.net + http://www.logicola.net/
>
> _______________________________________________
> Ror-es mailing list
> Ror-es@lists.simplelogica.net
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>



--
Sergio Gil Pérez de la Manga
e-mail > sgilperez@gmail.com
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras
348246701cfdb2130b842fd839751a18?d=identicon&s=25 Raul Murciano (raul)
on 2009-04-16 13:23
(Received via mailing list)
2009/4/16 Manuel González Noriega <manuel.gonzalez.noriega@gmail.com>:
> Hola,
>
> tengo un modelo con varios atributos que son escalas del tipo '0 => Mal, 1
> => Bien, 2 => Excelente'.  De las opciones disponibles: constantes en el
> modelo, constantes en un archivo de configuración, lookup tables, plugins
> estilo "app config" (http://www.google.com/search?q=AppConfig+plugin+rails)
> .. ¿Cuál es vuestra preferida? ¿Recomendaciones a favor y en contra?

Si sólo tienen relación con el modelo yo las suelo almacenar como
constantes en la clase, más que nada por tenerlo todo junto (si afecta
a la presentación y usas varios idiomas entonces creo que lo mejor es
seguir el consejo de Javier).
45742831d67c80d12cd7b24907b8d760?d=identicon&s=25 Sergio Gil Pérez de la Manga (Guest)
on 2009-04-16 13:23
(Received via mailing list)
Hola Manuel,

En el pasado he hecho cosas parecidas empleando una mezcla de
constantes en el modelo y unas gotitas de
metaprogramación:http://porras.lacoctelera.net/post/2008/01/13/un-t...

Más recientemente y en aras de usar la solución más simple posible +
evitar la optimización prematura, he hecho un poco lo mismo pero
usando directamente strings y validates_inclusion_of

Un saludo,

2009/4/16 Manuel González Noriega <manuel.gonzalez.noriega@gmail.com>:
> --
> Manuel,
> http://simplelogica.net + http://www.logicola.net/
>
> _______________________________________________
> Ror-es mailing list
> Ror-es@lists.simplelogica.net
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>



--
Sergio Gil Pérez de la Manga
e-mail > sgilperez@gmail.com
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2009-04-16 13:43
(Received via mailing list)
Niños, muchas gracias a todos (incluyendo a Diego, que me ha dado sus
tips
por Skype ;) Para esto que estoy haciendo en concreto no necesito nada
más
sofisticado que las constantes de modelo, porque es una prueba de
concepto,
poco más que unos wireframes interactivos, pero marco el hilo para
referencia cuando se trate de la app real. Porras, recuerdo cuando me
topé
por primera vez con código tuyo que utilizaba este sistema, me encantó
:)

Abrazos
8da2a535c50603e3252fb423b6005309?d=identicon&s=25 Christos Zisopoulos (Guest)
on 2009-04-16 14:46
(Received via mailing list)
Casi siempre uso constantes y con un truco para sacar el valor o el
texto:

class Profile < ActiveRecord::Base

   GENDER_CHOICES = {'m' => 'Hombre', 'f' => 'Mujer', 't' => 'Troll'}

   def gender(format = nil)
     return read_attribute(:gender) if format.blank?
     GENDER_CHOICES[read_attribute(:gender)] if format == :display
   end

end

Así puedo hacer:

  Profile.first.gender # Devuelve 'm'
  Profile.first.gender(:display) # Devuelve 'Hombre' para uso en las
vistas

...y tambien en las vistas:

   f.select :gender, options_for_select(Profile::GENDERS)

Con un macro de metaprogramación se puede especificar los campos de
ActiveRecord que tienen 'choices'
y crear los metodos on the fly. Algo
así:
class Profile < ActiveRecord::Base

   GENDER_CHOICES = {'m' => 'Hombre', 'f' => 'Mujer', 't' => 'Troll}
   AGE_RANGE_CHOICES = {18 => '18-30 years', 31 => '31-80 years', 81
=> '81-the death bed years'}

   attributes_with_choices :gender, :age_range

end

-christos
90ea347c45cdfbc1c5767dd6304d9c10?d=identicon&s=25 Borja Martín (Guest)
on 2009-04-16 16:25
(Received via mailing list)
yo el problema que le veo a esta aproximación es que estás dejando los
valores de las claves, que son los valores que luego vas a guardar,
dentro de ficheros asociados a las vistas, por lo que cuando añadas
nuevos idiomas, estarás duplicando la información de las claves(y con la
consiguiente posibilidad de tener incongruencias en los datos)

saludos
5c15703984caa012845b3cea129da936?d=identicon&s=25 Manuel González Noriega (Guest)
on 2009-04-17 11:31
(Received via mailing list)
2009/4/16 Christos Zisopoulos <christos@42linesofcode.com>

>   end
>
Estoy usando esta aproximanción, Christos, muchas gracias :)
Fc9813caa269ef26c419c56fe354eab6?d=identicon&s=25 Ayose (Guest)
on 2009-04-18 10:57
(Received via mailing list)
2009/4/16 Borja Martín <borjam@dagi3d.net>

>  yo el problema que le veo a esta aproximación es que estás dejando los
> valores de las claves, que son los valores que luego vas a guardar, dentro
> de ficheros asociados a las vistas, por lo que cuando añadas nuevos idiomas,
> estarás duplicando la información de las claves(y con la consiguiente
> posibilidad de tener incongruencias en los datos)
>


No tiene por qué. Tú puedes definir en el modelo el rango de valores que
admite ese campo, y a través de I18N darle texto a cada uno de esos
valores.

De las propuestas de este hilo la más limpia me parece la de de Javier,
especialmente de cara a aplicaciones que tengan que soportar varios
idiomas
This topic is locked and can not be replied to.