Logo de La Coctelera

Descubriendo el content_for

10 Abr 07

El otro día vi un Railscast sobre el content_for y sus posibilidades, y la verdad es que me gustó mucho. Voy a explicarlo con un ejemplo, porque la teoría no me la sé.

Imaginad que tenemos una acción de un controlador que requiere de una hoja de estilos especial, o de un Javascript especial, o que incluye un feed que el resto de acciones no tienen.

Para este tipo de casos podemos utilizar un bloque content_for y dejar algo muy limpio.

La vista de la acción podría ser así:


 <% content_for :head do -%>
 <%= javascript_include_tag :my_specific_javascript %>
 <% end -%>
 <h2>Cabecera de la vista</h2>
 Contenido contenido contenido....

Y en el layout simplemente debemos de incluír la llamada al bloque :head, tal que así:


 <html>
 <head>
  <title>Mi title</title>
  <%= javascript_include_tag :defaults %>
  <%= yield :head %>
 </head>
 <body>
   <%= yield %>
 </body>
 </html>

Lo bueno, es que el yield :head carga un contenido específico para cada acción que lo definamos, y si no lo definimos no carga nada. Lo cuál evita enguarrar el layout con ifs a tutiplén.

Lo malo es tener que incluír los requisitos de CSS, Javascript o lo que sea en la propia vista de una acción, que no me resulta del todo elegante.

¿Qué pensáis?

4 comentarios

4 comentarios

  1. 10 Abr 2007 | 10:20 AM # demimismo dice:

    Pienso lo mismo, me parece que al final queda poco elegante. Aunque depende para qué quieras utilizarlo, el ejemplo que has puesto del javascript no me parece nada mal, pero cuando lo utilizas por ejemplo para un sidebar... ahí es donde empieza a quedar muy sucio, prefiero hacer una variable de instancia y meter unos cuantos partials desde el controlador (por poner un ejemplo)

  2. 10 Abr 2007 | 11:17 AM # Ernesto Jiménez dice:

    Demimismo: content_for lo que hace es ir añadiendo los datos a una variable de instancia @content_for_head en este caso, cada vez que hagas un content_for 'head' los datos se añaden a esa variable, solo que lo haces desde las vistas, y una sidebar es cosa de vistasn, no de lógica de la aplicación :)

    A mí me gusta mucho content for para montarme un único layout para toda la aplicación, tengo un application.rhtml de un layout con mucha información contextual, que depende del controlador o de la acción en concreto, en vez de tener un layout por controlador tengo un único layout con yields que se populan con un partial por controlador.

    Ahora bien, hay un problema con content_for, y es que se ignora cuando cacheas ese fragmento de vista. Supongo que por el tema de que usa variables de instancia par montarlo todo.

  3. 10 Abr 2007 | 11:25 AM # demimismo dice:

    Gracias Ernesto, yo me refiero más bien a cuando un sidebar lleva algo de lógica de aplicación, como cuando tienes que mostrar contenidos relacionados en base a unas reglas determinadas, en esos casos me parece que sí estás metiendo demasiada lógica en las vistas.

  4. 10 Abr 2007 | 02:57 PM # nando dice:

    ¡qué bueno! no tenía ni idea de esto.

    a mí me parece que la idea es más que interesante. Es ideal para que dependencias de las vistas queden definidas explícitamente en las mismas.

    ¿no os ha pasado alguna vez que reciclando el código de una vista añeja os toca descubrir sus JSs y CSSs por prueba/error?

    si los problemas con la cache son únicamente con los fragmentos la cosa no es tan grave, se puede por convención colocar fuera. lo malo sería que no funcionase bien con la cache de acción.

Escriba un comentario: