Buenas prácticas: lookup hashes


#1

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!


#2

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 :wink:

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


#3

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-truquito-ejemplo-tonto-metaprogramacion-en-ruby-ruby-on

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 removed_email_address@domain.invalid:


Manuel,
http://simplelogica.net + http://www.logicola.net/


Ror-es mailing list
removed_email_address@domain.invalid
http://lists.simplelogica.net/mailman/listinfo/ror-es


Sergio Gil Pérez de la Manga
e-mail > removed_email_address@domain.invalid
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras


#4

2009/4/16 Manuel González Noriega removed_email_address@domain.invalid:

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).


#5

Niños, muchas gracias a todos (incluyendo a Diego, que me ha dado sus
tips
por Skype :wink: 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ó
:slight_smile:

Abrazos


#6

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-truquito-ejemplo-tonto-metaprogramacion-en-ruby-ruby-on

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 removed_email_address@domain.invalid:


Manuel,
http://simplelogica.net + http://www.logicola.net/


Ror-es mailing list
removed_email_address@domain.invalid
http://lists.simplelogica.net/mailman/listinfo/ror-es


Sergio Gil Pérez de la Manga
e-mail > removed_email_address@domain.invalid
blog > http://www.lacoctelera.com/porras
now > http://twitter.com/porras


#7

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


#8

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


#9

2009/4/16 Christos Z. removed_email_address@domain.invalid

end

Estoy usando esta aproximanción, Christos, muchas gracias :slight_smile:


#10

2009/4/16 Borja Martín removed_email_address@domain.invalid

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