Buenos días a todos.
Les escribo porque otra vez me surge una situación que se va haciendo cada vez más frecuente (por lo menos, para mí) y no se cuál sería el enfoque más adecuado desde lo semántico y desde lo técnico. ¿Cómo gestionar objetos compuestos dentro del Drupal?
Sucede a veces uno tiene que registrar múltiples objetos (cosas, entidades) que si son de información simple, se hacen con el cck. Por ejemplo, si alguien tiene que poner qué libros recomienda para un tema, y es sólo el título o un campo descriptivo, es suficiente con agregar un campo y decirle al cck que puede haber múltiples valores. Con eso, el cck agregar siempre 3 campos vacíos más al final de los llenos cada vez que muestra el formulario de edición. Vale lo mismo para bandas, artistas visuales (pienso en Leo) y cosas similares.
Pero ahora, imaginemos que el (múltiple) objeto a describir es más complejo porque está compuesto de más de 1 campo: por ejemplo, si pedimos libros como en el ejemplo anterior, cada libro tiene un título, un autor y una descripción. Recordemos que el usuario puede poner varios libros. Nuevamente, vale lo mismo para una banda (nombre, ciudad, año de creación) o un artista visual (nombre, ciudad, ámbito) o una serie cualquiera de obras.
No veo una manera directa de armarlo con el cck, aunque sí se me ocurre cómo simularlo (ya lo hice antes), creando cada campo por separado y mostrándolos ordenados como quiero en la presentación con el theme/node-content_tipodecontenido.tpl.php correspondiente.
Sin embargo, me suena a una solución muy poco elegante que pierde el sentido desde lo semántico, porque para el drupal hay varios campos autor, varios campos título, y varias descripciones, pero no configuran varios objetos "libro" compuestos por esos elementos.
¿Qué enfoque les parece posible/deseable/ideal para un caso así?
Desde ya, mil gracias. :-)
Saludos a todos...
PD: me encanta tener un grupo donde poder charlar estas cosas. Siempre me sentí muy solo con estas preguntas. Luego lo postearé también en inglés al grupo Relationships & site structuring (¿hay algún suscripto ahí?).
Comments
A ver...
Hola Eduardo,
Si no entiendo mal lo que planteás, en el fondo estás hablando de distintos tipos de contenido. En tu ejemplo, 'libro' sería un tipo de contenido totalmente independiente de su uso posterior en recomendaciones u otros contextos. Esa es la lógica subyacente.
Otra cosa es como ofrecer al usuario una interfaz para agergar muchos libros con facilidad - es decir, una creación 'masiva' de nodos. Ahí hay varias soluciones posibles. Si hay reutilización de items pasados (se pueden elegir libros que ya ingresaron otros), yo usaría un select list, o mejor aún, un campo autocompletar, y pondría un vínculo que abra una ventanita popup para agregar libros nuevos.
Como el autocompletar es dinámico, al cerrar el popup se actualiza inmediatamente y disponés del título que acabás de ingresar sin necesidad de refrescar el formulario original de recomendaciones.
Es lo que yo usé en el sistema de ingreso de muestras de un sitio de arte.
La idea esencial es que un objeto con varias propiedades es en el contexto de Drupal (o cualquier otro CMS) un tipo de contenido independiente, y no un conjunto de campos injertados en un tipo de contenido que en realidad modela otro objeto.
Leonardo Solaas
solaas.com.ar
Leonardo Solaas
solaas.com.ar
Múltiples objetos...
Hola Leo.
Así es. En éste caso no se usa en otro lado, pero sí podría en otros, lo que refuerza la necesidad de buscar una solución general.
En este caso, o hasta ahora, no es masivo. Serían pocos, y uno a uno porque cada uno crea los propios (en otras ocasiones, podrían reutilizarse, aunque no es éste el caso ahora).
Ahhh... por ahí viene la cuestión. :-) Esto me interesa porque no saca al usuario del proceso en el que está ahora, sino que le abre un pequeño paréntesis dentro del mismo y mostrándolo como un popup. ¿Cómo hacés lo de la ventanita popup?
Excelente. Esto es una solución, claramente. ¿Simplemente uso un autocompletar con un nodereference del cck y sale o hay que hacer algo especial para manejar la interfaz como decís?
Por eso preguntaba no sólo por la resolución técnica, sino además por la corrección conceptual. La posibilidad de crear los objetos in situ resuelve todos los aspectos:
Un millón de gracias Leo... :-)
Cuando lo tenga les aviso y muestro. Si hace falta, armo una receta.
Saludos para todos.
--
Eduardo Mercovich
--
Eduardo Mercovich
popup
Bueno, hacer el popup es bien sencillito. Basta con poner en la línea de descripción del campo (donde se eligen libros) un vínculo (al formulario de ingreso de libros) con el atributo target="_blank". Por ejemplo:
Si el libro que usted busca no está en la lista, por favor <a href="node/add/libro" target="_blank">ingrese uno nuevo</a>.Si querés ponerte exquisito, podés armar un template especial para la ventana popup, sin bloques ni encabezado... agregás algo que puedas reconocer a la url del vínculo (por ejemplo, la transformás en 'node/add/libro/popup'), y al principio de page.tpl.php te fijás si existe ese argumento, en cuyo caso incluís el template correspondiente.
Lo que no tengo idea es cómo se lleva el nodereference con el autocompletar - si se le puede poner esa propiedad así sin más. Como sabés, yo suelo trabajar con módulos a medida, así que no tengo experiencia en eso...
Un problema del autocompletar es que, a diferencia de un select, no impide el ingreso de un elemento que no esté en la lista. Entonces, hay que verificar que el item exista durante la validación del formulario - tampoco sé como maneja eso el nodereference.
Con un select no existe ese problema, pero claro, no se actualiza a menos que recargues la página entera.
Me alegro de ser util!!
Leonardo Solaas
solaas.com.ar
Leonardo Solaas
solaas.com.ar
popup
Qué bueno... pensando tanto en AJAX y CCK me olvidé del viejo HTML A... :-)
Me suena que sí... siguiendo esta idea de que el popup no interrumpa la experiencia anterior, cuanto más simple y liviano mejor. Si sólo tiene los campos necesarios y el botón (al que hay que agregarle un evento para que cierre la ventana), mejor.
Por supuesto, la palabra final la tiene la prueba de usabilidad con usuarios reales.
Bien, yo ya lo probé, y en un caso más complejo que lo normal (aquel con el problema del tiempo larguísimo de carga que charlamos en el grupo antes en Cómo diagnosticar un sitio lento.
Si está creado antes como decíamos, lo levantará solito. Pero eso no impide que el usuario ingrese uno que no existe.
Sin embargo, por lo menos para esta etapa, a mi me es suficiente ya que no son campos de información crítica.
En aras de una solución completa podríamos seguir con la charla, para que si alguien la necesita más adelante la tenga ya toda armada.
Por eso la combinación de autocompletar/noderefence es copada. :-)
¡Y mucho!
Gracias de nuevo...
--
Eduardo Mercovich
--
Eduardo Mercovich