Hace poco tiempo descubrí el módulo Content Templates , aunque ya se llevaba mucho tiempo trabajando en él (desde 2006).
Contemplate (nombre reducido) permite la modificación del avance y cuerpo de un nodo en Drupal desde la administración. Viene a solucionar una necesidad que sucede cuando se usan campos CCK para extender el formato básico de los nodos. Parte del problema es que Drupal considera que todos estos campos forman parte del body y cuando se muestran avances se muestran todos estos campos. Por otra parte, no existe una forma cómoda de ocultar, por ejemplo, algunos campos (perdón, úsese CCK Field Privacy) o etiquetas de campos (con técnicas CSS!).
El caso es que es engorroso y Contemplate lo pone, en principio, un poco más fácil. Tanto que sólo tienes que elegir crear una nueva plantilla para un tipo de nodo, decidir qué parte se modifica (teaser, body, rss) y voilà! dónde está mi contenido?
Lo primero que no me gusta de este módulo, y que no sirva como una crítica destructiva si no como una manera de valorar su uso según qué casos, es que se requieren tantos conocimiento de HTML/PHP que si tuvieras que customizarte tu propia forma de visualizar un nodo.
En segundo lugar, no sé por qué (quizá es que no he sabido usarlo correctamente) desaparece automáticamente lo que guardamos en el campo body y esto hace que tengamos que estar prevenidos y no se nos pase crearnos un cck tipo texto para poder guardar el cuerpo.
En tercer lugar, parece ofrecer una forma nueva con la que referenciar los campos cck de la que desconozco la potencia o lo nuevo que ofrece (si alguien la sabe, por favor que me informe que estoy pez). El caso es que, en mi opinión, usando el campo Devel (si no lo usas normalmente te lo recomiendo para todas tus instalaciones) es más que suficiente para saber cómo hacer referencia con PHP a las variables que lo muestran.
Entiendo que es duro tener que pensar que hay que saber programar para poder manejar el sistema de plantillas de Drupal, ya que esto hace el trabajo de maquetador mucho más pesado. Existen alternativas como Smarty (todavía no lo he probado aquí, pero me gustaría verlo en funcionamiento), el caso es que es una realidad. Contemplate resuelve de forma rápida una serie de limitaciones que tiene el CMS y me gustaría decir que es la mejor opción para quien no quiere oír de programación. Pero no es así.
En cuarto y último lugar, este módulo como muchos otros se interponen de una manera indirecta en una clara separación, y en mi opinión necesaria, de las tareas de maquetación y administración. Es más un problema de metodología de trabajo: ¿quién tiene que preocuparse de cómo se muestra un tipo de contenido, de qué etiquetas HTML deben usarse, de cuándo o cómo poder modificarlo?
En este sentido creo que siempre será más fácil trabajar en un proyecto en el que se separen al máximo estas tareas, que un maquetador no necesite nada más que su cuenta FTP directa al directorio de themes para poder hacer lo que quiera sobre el aspecto del sitio... claro que este argumento destrozaría la utilidad del sistema de bloques!! ups... bueno, quizá no tenga razones reales para no usarlo, una vez más, es cuestión de costumbres.
pd: estoy totalmente a favor del sistema de bloques y de que exista gente que trabaje tan duro como se ha hecho con el proyecto Contemplate.
Comentarios
Soy un "ferviente" usuario de contemplate ;) y pienso que es la forma mas sencilla de darle "estilo" a los contenidos, aunque claro, esto es mas para programadores...
En cuanto a tu problema 2, no desaparace, esta con otro nombre $node->content['body']['#value'] :P
claro, y esa es mi pregunta, si ya tenemos ese "problemilla" por qué se inventan uno similar?
jeje, me alegro de que te ayude: 1-1
Kaixo Carmel
Completamente de acuerdo con lo que comentas, yo cuando lo descubrí se me abrió el cielo. Pero luego empezaron los problemas que comentas.
Para mi el temas es como comentas una cuestión de metodología, nosotros en el equipo los perfiles son muy claros y la personas que diseña y que es diseñadora de la linea dura :) ha tenido que reciclarse lo justo para comprender $node->content['xxx']['#value' y bastantes mas historias de hmtl/php de las que ella hubiera imaginado en un principio, pero creo que los departamentos estancos en el desarrollo web ya no se si es interesante, hay que saber un poco de todo para comprender que se esta haciendo.
Smarty mola, pero al final es un seudo código casi tan posibilista como php, osea aprender sintaxis, particularidades y añadir otra capa mas al performace.
Salur
A mi tampoco me gusta el contemplate, prefiero usar bloques, y añado el panels también a la lista, creo que añadir módulos que no facilitan excesivamente la tarea y pueden llegar a complicarte la vida en un momento dado,... De todas formas, también hay que decir que si te vas a remangar y tocar templates, es mejor empaparte de cómo funciona el sistema de templates de drupal antes que conocer como funciona un módulo en particular.
Buen post, yo la verdad conocí este módulo con Drupal 4.x y te puedo asegurar que en 5.x cambió a peor. Era mucho más sencillo de utilizar, al menos para mí (que mi nivel de programación es bajo) y se podían configurar muchos más detalles de cada tipo de contenido que en 5.x.
También te comento que en la versión anterior lo había trasteado mucho más, en esta me desespera un poco por los detalles que comentas.
Pues yo soy el que raro, pero si me gusta mucho el módulo.
Es cierto que hasta que consigues cogerle el truco de como funciona bien es un poco lioso, pero luego es una gozada.
Respecto a lo que comenta Karlos sobre la división de departamentos. Tengo una conocida que es diseñadora gráfica de toda la vida, y por lo que me cuenta de los eventos de diseñadores gráficos, todo dios anda como loco porque ahora para hacer Webs dinámicas hay que conocer mínimo css/js/ y luego el lenguaje en el que este construida la web.
Creo que el perfil, a caballo entre diseño gráfico y programador, experto en montar plantillas para entornos dinámicos es una realidad ya.
Un saludo
Oskar
karlos: ese es otro problema además, el del diseño, para poder explicar de una forma sencilla a un/a diseñador/a las limitaciones de drupal lo mínimos es enseñarle que está organizado de forma lógica, aunque al final "todo se pueda hacer"...está claro que al final cuanto más se conozca a Drupal más ágil es el desarrollo.
pedro: totalmente de acuerdo, es mejor dominar bien el sistema de plantillas sobre todo cuando tu tarea está especializada en eso: maquetación.
carmen:si has conseguido lidiar con él no hay duda...
oskar: creo que estos módulos son muy útiles cuando te toca hacerlo todo, en cuanto a los diseñadores con los que he podido trabajar tiene claro dos cosas: deben saber qué pueden hacer y dónde están los límites, pero tampoco sufren por esto (creo) es más bien que saben que ni quieren que el maquetador se invente nada, ni quieren tener que repetir un trabajo.
Enviar un comentario nuevo