Podría ser el título de un disco de rock progresivo, pero no.
Las palabras reservadas son una serie de palabras que, al ser utilizadas internamente por RoR, no podemos utilizar nosotros para nombrar las entidades (Modelos, Controladores) de nuestra aplicación.
La lista completa está recopilada en el wiki oficial: ReservedWords
A los angloparlantes (o angloprogramadores) les puede resultar fastidioso no poder nombrar algo "Object" (imaginemos, en una aplicación para subastas). Pero bueno, siempre puede uno echarle imaginación y llamarlo "Item" o "Article".
En este caso los usuarios internacionales tenemos ventaja, porque es muy difícil encontrar una palabra en esa lista que nos cause problemas.
Mirando en esa misma página, he encontrado otra lista muy interesante: la de campos mágicos, que son columnas que podemos añadir a nuestras tablas y RoR escribirá cosas en ellas automáticamente y gratis. Por ejemplo si añadimos un campo created_at, RoR mete en eses campo automáticamente la fecha de creación del registro.
El tema de las pluralizaciones automáticas con RoR ha sido siempre posiblemente el más polémico aspecto de este framework. De vez en cuando aparecen hebras en la lista de correo en la que vuelve a salir a relucir este tema.
Empecemos hablando brevemente de cómo se nombran las "cosas" en Rails:
Las clases que representan nuestros Modelos se nombran con la primera letra en mayúsculas y usando mayúsculas y minúsculas cuando están compuestas por varias palabras, por ejemplo WebServer. (De momento ponemos los ejemplos en inglés, ya veremos por qué).
Las tablas se nombran en minúsculas, por ejemplo customers.Rails es capaz de adivinar que tabla asociar a un Modelo determinado. Si la palabra es compuesta son compuestas se separan con el guión bajo, por ejemplo Rails asociaría automaticamente el modelo WebServer con la tabla web_servers.
Además Rails es inteligente con los plurales y asociaría el modelo Person con la tabla people.
Esto permite usar en las relaciones entre clases, una sintaxis más parecida al "lenguaje natural":
class Customer < ActiveRecord::Base
has_many :web_servers
end
Si por alguna razón no queremos que Rails pluralice nuestros nombres de tabla, sino que el nombre del Modelo sea igual que el de la tabla, basta con introducir en el fichero config/environment.rb:
ActiveRecord::Base.pluralize_table_names= false
Además si estamos utilizando un nombre de tabla que Rails no va a poder adivinar podemos decirle explícitamente que nombre usar:
class Customer < ActiveRecord::Base
set_table_name "t_customerdata"
has_many :web_servers
end
Esto puede ser útil en castellano porque las reglas de pluralización no se adaptan bien a nuestra lengua:
ServidorWeb estaría asociado a la tabla servidor_webs en lugar de servidores_web.
Para los que queráis bucear en esto, las reglas de los plurales están en el módulo Inflector, en el método plural_rules.
Y si os apetece probar como pluraliza Rails sin necesidad de bucear en el Inflector, el Pluralizer de nubyonrails es muy útil.
Dependiendo de la forma de nombrar las entidades en nuestra aplicación dependerá si podemos usar esta pluralización automática o no, aunque no cabe duda de que en castellano resulta mucho menos útil que en inglés.
Esta mañana, a raíz de una pregunta en la lista de correos, he estado haciendo un pequeño experimento, a ver cómo se comporta RoR cuando se utilizan nombres de columnas (y datos) con caracteres acentuados o eñes.
Si eres impaciente, puedes saltar directamente a las conclusiones
.
A pesar de los acentos y las eñes en los nombres de columnas, no aparece ningún error al crear la tabla, funciona.
Luego metemos un registro para tener algún dato:
sqlite> insert into ni\303\261os values (1,'Casta\303\261o','Sof\303\255a');
sqlite> select * from ni\303\261os;
1|Castaño|Sofía
A continuación generamos el scaffold para ver que obtenemos:
eduardo@[~/desarrollo/test]: ruby script/generate scaffold Ni\303\261o
dependency model
wrong constant name Niño
Ésto sí que no se lo traga. Así que ponemos Nino y vemos el resultado:
Parece que ha cogido bien las columnas pero no visualiza bien ni los nombres ni el contenido.
Al tratar de añadir el nuevo registro, veo que no aparece formulario. Investigando un poco más, resulta que el formulario no aparece en app/views/ninos/_form.html. Debe ser que se ha hecho un lío con los nombres de las columnas al generar el scaffold.
Metemos el código a mano:
<%= error_messages_for 'nino' %>
<%= text_field 'nino', 'árbol' %>
<%= text_field 'nino', 'nombre_niño' %>
Y Bingo, parece que funciona bien la edición:
Y además sale el contenido de los campos visualizado de forma correcta.
Conclusiones
Las columnas de tabla con caractéres españoles (y por lo tanto los métodos de las clases que se derivan de ellos) funcionan con Ruby on Rails.
Hay cosas de RoR (partes del scaffold) que no funcionan bien con las columnas con caracteres españoles, aunque aparentemente los problemas son fácilmente solucionables.
Los datos con caracteres españoles no deben suponer ningún problema. Esto es bastante obvio porque llevamos toda la vida metiendo nuestros nombres con sus acentos y eñes en las BBDD.
Trabajar con caracteres acentuados en otro sitio que no sean los datos es un rollo: No se si será por el editor que he usado (ver abajo) o por otra razón, pero constantemente salían los caracteres mál visualizados: bien como códigos estilo \xxx como ? o en el navegador cómo à y cosas por el estilo.
No creo que merezca la pena complicarse la vida con poniéndo los nombres de columnas con caracteres españoles, a menos que tenga una justificación clara, nadie nos garantiza cómo va a funcionar con distintos sistemas y Bases de Datos.
Detalles técnicos
Esta prueba está hecha con:
La última versión de rails (0.13.1) corriendo en un iBook G4 con Mac OS 10.4.2.
