Las herramientas están para ayudarnos a lograr nuestro trabajo con la mayor eficiencia posible. Cuando usamos todo lo que nuestro material de trabajo nos ofrece somos más productivos y más felices.
En Drupal, cuando se están estilizando páginas o contenidos, es muy común apoyarse en clases para los nodos, las secciones, las regiones o los mismos bloques de contenido.
Si uno se toma el tiempo de inspeccionar el HTML que genera una página Drupal, se da cuenta de que hay muchas etiquetas y clases para cosas que se pueden lograr con menos, sin embargo, es mejor que estén ahí. Son una gran ayuda.
Tener tantas clases disponibles permite discriminar los estilos por páginas o regiones de una misma página. Ejemplo: en la página “contacto” es muy posible que haya una clase
page-node-x
donde x equivale a un número que es el id del nodo en la base de datos. Esto permite tener clases que ayudan a saber en qué página se está. Todo mediante CSS.
Algo así pero en Rails
Me encontraba haciendo debug a un pequeño problema de una implementación con jQuery y necesitaba poder tener clases para identificar en qué acción del controlador estaba.
En Rails, por convención, el formulario de un modelo se crea como partial y se reutiliza en las vistas new y edit, lo que significa que colocar una clase manual no sería de ayuda, ya que estaría disponible en ambas vistas.
Para mi fortuna, el controlador envía a las vistas un array de parámetros que podemos utilizar a nuestro beneficio.
<%= params[:action] %>
Con ese array pude crear una clase personalizada añadiendo el nombre de la acción del controlador. De la misma forma se puede obtener el id del objeto actual con
<%= params[:id] %>
El anterior código funcionaría para nested routes (no sé cómo traducir eso a español), ejemplo: /users/1/tasks
Donde el código arriba devolvería el valor del id del usuario, o sea, el número 1.
Respuesta encontrada en Stack Overflow.
Un detalle clave al usar la gema Nested Form
La gema de Ryan Bates, nested_form permite, desde un único formulario, guardar información a varios modelos (tablas) que guardan alguna relación. De esta forma el usuario no tiene que ir de un formulario a otro para crear contenido.
En los casos donde se usan nested routes para modelos que pertenecen a otro, hay que tener en cuenta que el id del modelo padre tiene una forma particular para agregarse a los atributos permitidos.
Supongamos que tenemos la ruta:
resources :users do resources :tasks end
y hay un formulario para guardar las tareas de un usuario, la lista de parámetros permitidas no debe ser así:
#1
params[:task].permit(:user_id, :task_name)
Sino
#2
params[:task].permit(:task_name).merge(user_id: params[:user_id])
Wow, wow, más despacio cerebrito
Explico. En la forma #1 el array de parámetros quedaría así:
{
user_id: 1,
task: {
task_name: "Your task"
}
}
De esa forma, en el controlador que espera el array de nombre “task” no recibe el user_id ya que no viene dentro de ese arreglo de datos.
La segunda forma resuelve ese detalle haciendo una unión entre los dos parámetros que viajan separados, agregando finalmente el user_id al array task.
Esta respuesta la encontré en Stack Overflow 🙂
Imagen: Jose Rojas.
