Comenzar con una definición debería ser lo más sensato. Pero al tratar de aplicar una perspectiva general la situación se torna ambigua, y a menudo se generan discusiones un tanto pintorescas sobre lo que es y lo que no es un sistema de gestión de contenidos (en inglés CMS). Pero esta sección no es la de debates, y en cualquier caso tampoco me parece una discusión demasiado productiva, de manera que correré el riesgo de no contentar a todo el mundo con la definición. Un CMS es un sistema que nos permite manejar nuestro capital documental de forma que se puedan realizar diversas acciones con su contenido, como editar, organizar o publicar. Existe una convención con bastante aceptación merced a la cual se debe distinguir entre dos elementos fundamentales: el contenido (un artículo, una foto, etc. tal y como se almacena o archiva) y la publicación (el proceso de representar esos contenidos o el resultado final).

La prudencia dicta que, antes de embarcarse en la tarea de crear un CMS propio, se dé uno un garbeo por la red para ver si alguno de los existentes (Zope, Drupal, Movable Type, etc.), se adapta a nuestras necesidades. Si no se encuentra ninguno, puede ser un buen momento para desarrollarlo por nuestra cuenta. El tratamiento que del tema se hace en este taller es muy simple, por lo que quizás no responda a los intereses de ciertos visitantes, en especial si buscan profundizar en el tema o informarse sobre productos específicos.

Porque necesito que el sitio que mantengo:

• Precise almacenar diferentes versiones (fecha, autor, etc.) de cada documento.
• Permita compartir y actualizar documentos a varias personas en diferentes entornos y con conocimiento desigual sobre el sistema.
• Disponga de un sistema flexible y eficiente de búsqueda, indexado y consulta de documentos.
• Sea capaz de servir un mismo documento en formatos diferentes (XHTML, PDF, etc.).
• Ofrezca servicios interactivos para el usuario, como acceso restringido, personalización de la interfaz, publicación de comentarios, etc..
• Esté formado por documentos (de cualquier tipo, no sólo escritos) y para su presentación se requiera una parte o estructura común, independiente de ellos, pero que los contenga adecuadamente (menúes de navegación, etc.).

El último punto es el que más autores de webs demandan. Algunos tratan de cubrir esa necesidad usando conjuntos de marcos, pero son francamente desaconsejables en la mayoría de los casos, y por otro lado tampoco sirven para realizar una gestión mínimamente eficiente, dado que no pueden mezclar contenidos con independencia de la distribución que impone el propio conjunto: no son un sistema de gestión, sino de colocación.

La tecnología conocida como inclusiones del lado del servidor (en inglés SSI) constituye probablemente el sistema más simple técnicamente hablando. Mediante SSI podemos embeber en el código HTML ciertos comandos que serán procesados por un intérprete en el servidor, entre los cuales hay uno que nos permite incluir el contenido de un archivo:

Para algunos, el hecho de que el documento final sólo sea accesible cuando es procesado por el servidor web es una desventaja, dado que no se puede probar en modo local, como si fuera un documento HTML convencional. Esto se soluciona instalándose un servidor web para procesar localmente los documentos, pero contamos con opciones menos drásticas: existen editores y herramientas capaces de representar documentos con SSI como si hubieran sido procesados.

SSI permite incluir contenido generado dinámicamente, por ejemplo mediante la ejecución de un script CGI, lo cual es muy útil en ciertas ocasiones. Un ejemplo muy sencillo: omitir en un menú de enlaces el correspondiente al documento actual. Pero es evidente que este sistema no admite demasiadas complicaciones. Cuando se precisa más flexibilidad se opta por sistemas basados en la combinación de una fuente de datos y un lenguaje de programación, pero eso ya es otra historia...

No tiene por qué existir una concordancia entre lo que un autor aporta y lo que el usuario final recibe. De hecho lo más sano es que no sea así. El primero puede escribir un artículo y el segundo obtener una página web que incluye dicho artículo debidamente formateado, pero también otros elementos. Sin ir más lejos, en esta misma página: una cabecera, un menú de navegación, un bloque de comentarios (si es que los hay), un cuadro de búsqueda y un formulario de sugerencias. Y, por supuesto sin tocar el contenido original, el resultado podría ser otro, tanto dentro como fuera del contexto de las páginas web.

Tampoco hay que dar por supuesta una relación uno a uno, porque puede darse cualquier combinación. Una publicación final puede responder únicamente a un fragmento de un contenido original, a la totalidad de varios contenidos simultáneamente, y a todo el rango de ocurrencias posibles entre ambos casos, por ejemplo un índice que incluya fragmentos de cada una de sus entradas.

Una buena gestión pasa por un análisis detallado de cada una de las piezas de las que se compone un documento, y de su posible sistematización. Por ejemplo:

• Encabezados HTTP (por ejemplo los relativos a la gestión del caché).
• Título.
• Datos para elementos meta (descripción, palabras clave, etc.).
• Vínculos o referencias a archivos externos (scripts, hojas de estilo, etc.).
• Elementos link auxiliares (author, help, navegación, etc.).
• Bloques comunes dentro del cuerpo del documento: menúes de navegación, formularios de búsqueda, bloques contextuales, etc..

La idea es que nuestro sistema tenga, para cada contenido y publicación, información sobre todos esos datos. Como ya se apuntaba antes, a nada que tratemos de complicar el asunto, el uso de tablas de datos se hace indispensable, y un lenguaje con el que poder manejarlas también. Pero eso excede los límites de este taller introductorio. Quizás en otra ocasión.

En esencia contamos con dos modelos de publicación en cuanto al momento en que el documento final es generado:

• Directo: la publicación es construida en el momento en que se solicita, a partir de los contenidos necesarios.
• Diferido: cuando se crea o modifica un contenido se generan y guardan todas las posibles publicaciones que lo contienen.

Ambos tienen sus pros y sus contras. El primero es más flexible, y al no existir físicamente las publicaciones se ahorra espacio de almacenamiento. El segundo no tiene tantas posibilidades de consulta pero por otro lado ahorra recursos: en el servidor, porque no es necesario ejecutar ningún proceso cuando se produce la petición; y en la red, porque pueden utilizarse las cachés de un modo más exhaustivo.

Una opción intermedia podría consistir en aplicar el método diferido sólo para los documentos más solicitados. Esto aligera la carga del servidor y no merma la flexibilidad del sistema.

Cuando hablamos de páginas personales, sin ningún presupuesto económico, es fácil lamentarse: ¿de qué sirve todo esto si el servidor donde las alojamos no admite ni siquiera SSI? Es una situación típica, porque la inmensa mayoría de los proveedores gratuitos no ofrecen tecnologías de este tipo. Pero eso no implica que no podamos utilizarlas en nuestra propia computadora, escogiendo un modelo de publicación diferida.

Escribe un comentario

Expresa tu opinión sobre este recurso y compártela con los demás.

ExcelenteBienPasableRegularMejor lo quitáis Valoración

Nombre (requerido)

Email (requerido, no será mostrado)

Web (opcional)

Título

Escribe aquí tu comentario

Validación

Por favor, introduce abajo el texto que se muestra en la imagen. De ese modo, evitamos los envíos automáticos masivos y podemos contestar antes a los mensajes legítimos como el tuyo.