Buenos días a todos.
He aquí otra vez un caso particular que representa un caso general. Si tengo objetos de muy similar estructura pero diferente sentido ¿creo diferentes tipos o los tipifico con taxonomías?
Posteo la pregunta a ver si a otros les pasó y, en ése caso, si podemos discutir pros y contras de cada opción.
En este caso puntual, tengo un sitio con varios tipos de contenido entre los que hay:
* resumen de capítulos,
* autoevaluación,
* modelos interactivos,
* etc.
Todos estos tipos tienen la misma -o casi- estructura:
* nombre,
* cuerpo, y
* un adjunto opcional.
Frente a esta situación, veo como mínimo 2 opciones (¿alguien tiene otras?):
a. Creo diferentes objetos que comparten campos del CCK (nombre, cuerpo, adjunto, etc.).
b. Creo un único objeto al que le aplico una taxonomía (con miembros como resumen..., autoevaluación..., etc.) para asignarle el tipo.
En ambos casos, puedo crear, editar, acceder, organizar y buscar el contenido con todos los módulos estándares. Pero no son iguales desde lo semántico ni desde la implementación.
¿Hay algún criterio -o se les ocurre algún impacto importante, limitación o similar- que haga que una opción prime sobre la otra?
En mi caso actual, no todos los objetos tienen exactamente la misma estructura, lo que puede empujar la decisión más hacia la opción 'a', pero me parece interesante la pregunta y el análisis de impacto.
Desde ya, disculpas por la pesadez y gracias adelantadas por las respuestas. :-)
Saludos...
Comments
Diferentes tipos de contenidos o taxonomias?
Pensando en voz alta, fijate que vas sumando para tu decision.
Diferentes tipos de contenido creo te va a dar mas facilidad al momento de dar permisos (ver, editar, etc), sobre todo si son entidades diferentes puede que en algun momento deban ser manejadas por personas diferentes (para manejar permisos con las taxonomias creo que igual hay un modulo por ahi). Lo mismo para retirar algun tipo de contenido de publicacion. Mas flexibilidad con Pathauto (vas a tener la opcion para cada tipo de contenido).
En cuanto a la taxonomia, aun siendo tipos de contenido diferentes, pueden compartir algunos o ningun vocabulario.
Si solo va a tener titulo, cuerpo e imagen, no necesitarias CKK, te arreglas creando los contenidos nuevos con el set de Drupal standard (5.x) o con el modulo ContentO (si 4.7x).
Saludos
Gustavo
Gustavo
A mí me ha pasado
A mí me ha pasado tener nodos con estructuras muy similares que me ponían en la diatriba de crear un nuevo tipo de contenido o no.
Tal vez si son "exactamente" iguales en la estructura, es mejor usar las taxonomías. Como bien señalaron, el tema de los permisos para las taxonomías tiene un par de módulos que te pueden servir (hay dos con nombre similar que no recuerdo, el segundo tiene el agregado "Lite" al final, que es el que uso y lo recomiendo es muy flexible).
Si por otra parte uno de esos tipos de contenido tiene algunas diferencias, definitivamente te aconsejo crear diferentes tipos (yo aún uso flexinode en mi instalación 4.7... Víctor no te enojes, je).
A mí me pasó, por ejemplo, que tenía un mismo tipo de nodo "archivo", con cuatro taxonomías:
Legislación Nacional
Legislación Ciudad de BsAs.
Legislación Provincial
Novedades
Las tres primeras eran exactamente iguales en estructura, y la cuarta, pese a tener una estructura similar a las anteriores, permitía el posteo de "comentarios", mientras que las otras tres no.
Parece mentira, pero una pavada así puede complicarle la vida a uno. Fueron infinitas las veces que olvidaban tildar o destildar el "allow comment", y decidí crer dos tipos de nodos:
Legislación y Novedades.
El primero (legislación) contenía tres taxonomías (Nacional, Provincial y Ciudad de BsAs) mientras que el segundo una sóla (Novedades).
Así se me hizo más fácil el control de lo posteado por los autores.
Igualmente trato de no crear distintos tipos de nodos a menos que sea estrictamente necesario... (como en este caso que tenía que estar todo el tiempo atrás del que posteaba las novedades o la legislación con o sin los comentarios habilitados...)
A ver qué opina la muchachada sobre esto...
Saludos!!
Rosamunda
Control de autores y permisos.
Hola.
Surge otra vez entonces el tema del control... como en el post anterior.
¿Porqué? Éstas son las experiencias que me interesa comparar.
Gracias y saludos...
--
Eduardo Mercovich
--
Eduardo Mercovich
En cuanto a la cantidad de tipos de nodos...
En realidad trat(aba) de no crear nuevos tipos de contenido porque, en mi ignorancia, creía que podrían consumir más recursos del sistema...
Gracias a la muy clara explicación de Leonardo (muchas gracias!) he cambiado de opinión al respecto, inclusive me parece que -según entendí- la cosa podría ser exactamente al revés: Abusar de las taxonomías sí podría llegar a consumir más recursos en cuanto a la cantidad de consultas a las tablas, haciendo la carga de la página más lenta.
Respecto del tema del control, creo que esta cuestión se entrelaza con tu pregunta original, ya que sin perjuicio de que crees más taxonomías, o más tipos de contenido, siempre tu decisión estará en función de la flexibilidad que querrás tener en el orden/archivo/búsqueda del dichos contenidos por un lado, y separar quiénes sí y quiénes no puedan modificar qué clase de cosas.
Por cierto Eduardo, el tema que planteaste me pareció sumamente interesante, sobre todo porque tarde o temprano creo que todos nos preguntamos lo mismo.
Saludos!
Victoria
que importante
Que importante este envío! Cuanto más dialogo tenemos sobre estos puntos, mejor vamos a poder trabajar!
Victor Kane
http://awebfactory.com.ar
Victor Kane
http://awebfactory.com
Sobre permisos y taxonomias...
...ver mis comentarios arriba: fijate forum_access (usa acl para controlar permisos sobre taxonomia).
Si te interesa, abrí un "thread" sobre el asunto y lo podemos profundizar con ejemplos.
Victor Kane
http://awebfactory.com.ar
Victor Kane
http://awebfactory.com
Diferentes tipos de contenidos o taxonomias?
Hola.
El tema de los permisos es uno de los impactos importantes, más allá de que el taxonomy access control (completo o lite, hay un buen artículo del tema en http://www.lullabot.com/articles/private_forums_in_drupal_forum_access_v...) .
Lo del pathauto me gusta, aunque no es fundamental en este proyecto. Pero como decíamos antes, la idea es discutir el caso en general para aprovecharlo entre todos.
Muchas gracias por tus aporte... :-)
--
Eduardo Mercovich
--
Eduardo Mercovich
Desde el punto de vista
Desde el punto de vista estrictamente conceptual, las taxonomías deberían usarse para distinguir, digamos, 'especies' de un mismo 'género'. O, en otras palabras, para hacer clasificaciones internas dentro de un mismo tipo de objeto.
Cualquier otro uso de ese sistema es un invento, en el sentido de que es aplicarlo a fines que no le son propios.
Que dos tipos de contenido tengan la misma estructura de campos es una mera coinicidencia. De por sí, eso no los emparenta ni los hace miembros de un mismo género.
Ahora bien, en mi experiencia, lo conceptualmente correcto es también, a fin de cuentas, siempre lo mejor desde el punto de vista práctico. El ejemplo de Rosamunda es perfecto en ese sentido. Los tres tipos de legislación son en efecto clasificaciones de lo mismo, mientras que las novedades son conceptualmente diferentes.
Esa situación forzaba a los usuarios a tener que hacer la distinción ellos mismos tildando la casilla de permitir comentarios. Pero estaba muy bien que se olvidaran, porque la ontología del sistema no es un problema del usuario, sino del desarrollador.
Es decir, usar una taxonomía en un contexto como este es 'aprovechar' una similitud de estructura que puede dejar de serlo en cualquier momento, porque conceptualmente se trata de objetos diferentes, y la evolución del sistema o un requisito nuevo del cliente puede terminar con esa similitud de un plumazo.
Por último, desde el lado práctico tampoco hay motivos para ser amarrete en la creación de tipos de contenido. Digamos que 'a Drupal le da igual'. Ya que en cualquier caso todo va a parar a la tabla node, no consume más recursos. Incluso puede ser marginalmente más eficiente en sitios grandes, porque el filtrado se hace por la columna 'type' en la misma tabla 'node', en lugar andar haciendo pesadas consultas de unión con 'term' y 'term-node'.
Leonardo Solaas
solaas.com.ar
Leonardo Solaas
solaas.com.ar
Desde el punto de vista estrictamente conceptual...
Bien, vamos entonces llegando a un punto común.
Al parecer, es mejor en casi todo caso utilizar tipos diferentes.
Chicos/as, ¡muchas gracias!
Lo vuestro es ejemplar... :-)
Saludos...
--
Eduardo Mercovich
--
Eduardo Mercovich
Solo para saludar y apoyar tu mención
Al leer el hilo, coincido con el concepto que dejas del contexto de la información por encima de la forma.
Este tipo de resoluciones en el momento del análisis del contenido a publicar es fundamental.
Además que es la esencia del Framework basarse en el nodo (por tipo de contenido) y sus posibles ampliaciones.
Muy buenos aportes de todos para comparar y tomar un decisión que se ajuste a las necesidades.
Saludos.
Discusión fascinante! Algunos aportes.
Primero, acuerdo con Leonardo en que solo debe tratarse de clases de tipos semanticamente emparentado (los que en un paradigma orientado a objetos conformarían una jerarquía) si no, es un invento, como dice Leonardo, y, yo agregaría, no es reutilizable para nada en el futuro.
Una tercera opción: Se puede usar un campo de selección que se llama "tipo" en vez de vocabulario (aparece como botonera de radio o como checklist), un campo que se puede usar en distintos objetos también. Por ejemplo, en una aplicación CRM-lite que he instalado para un cliente, hay un único tipo de contenido "asunto", que puede ser utilizado como "tarea", "llamada", "prospecto para la venta", etc. El flujo de trabajo ayuda a que los usuarios quieren tildarlo, no se presenta problema por eso (y por eso se puede usar).
Entonces, podés palanquear la magia de views usando el tipo como arg!!!
Luego, podés usar el view o como tal (con arg) en un panel (modulo Panel) o como embed en tu theme, o (más flexible) con items!!! Por ejemplo:
<?php$view = views_get_view('Asuntos');
// $las_llamadas = views_build_view('embed', $view, array(0 => 1), false, false);
// $las_tareas = views_build_view('embed', $view, array(0 => 2), false, false);
// $las_llamadas = views_build_view('embed', $view, array(0 => 1), true, 10);
// $las_tareas = views_build_view('items', $view, array(0 => 2), false, false);
$las_llamadas = views_build_view('items', $view, array(0 => 1), false, false);
?>
La documentación para esto está en la línea, más o menos, 350 de views.module: cosas que ni nos podrían haber imaginado antes. "embed" te da el html, "items" un hash con los datos!
Pero es igualmente útil en Panels, sin programar (podés especificar el arg, o sea, "tipo").
Bueno, si a alguien le interesa profundizar por allí, avisáme, y lo seguimos.
Con respecto a los permisos, ver la excelente clase (acabo de subir los apuntes (en inglés)!) sobre node access en Drupal 5. Usando un hook tumodulo_db_rewrite_sql en tu modulo podés arreglar lo de los permisos hasta de taxonomia (se explica allí incluso como lo hace forum_access con el módulo acl).
Lesson #8 Class Notes wiki -- db_rewrite_sql() and the Drupal 5's node_access system
Muy útil, y también una fuente de ideas impensados (Drupal es profundo!).
saludos,
Victor Kane
http://awebfactory.com.ar
Victor Kane
http://awebfactory.com.ar
Victor Kane
http://awebfactory.com