Página, diseño, slot y bloque: qué aporta cada separación
Una forma práctica de decidir si una capa de modelo de contenido absorbe el cambio o simplemente añade ceremonia.
El modelo de contenido principal WebBlocks CMS cabe en una línea:
Page -> Layout -> Slots -> Blocks
Esto puede parecer una jerarquía útil o una ceremonia innecesaria. ¿Por qué no almacenar una página como un árbol de componentes y renderizarla? Ese enfoque es válido para muchos productos. Cuatro capas explícitas ganan su lugar sólo cuando cada una posee un tipo diferente de cambio.
Página: identidad, enrutamiento y estado editorial
Una página responde preguntas sobre el documento como objeto publicable: qué sitio es el propietario, cuál es su ruta pública en cada ubicación, si está en borrador, en revisión o publicado, qué diseño utiliza y qué metadatos, activos e historial de revisión le pertenecen.
Esas preocupaciones sobreviven cuando cambia el contenido visible. Reemplazar un héroe, mover un párrafo o agregar una galería no debería crear una nueva identidad de enrutamiento.
Lo contrario también es útil. Mover o duplicar una página se puede tratar como una operación de página controlada. El sistema sabe qué traducciones, espacios, árboles de bloques de propiedad de páginas, activos y relaciones de revisión viajan con él. Una página es más que el nodo raíz de una matriz de componentes.
Diseño: la promesa estructural
Un diseño define qué regiones puede tener una página y cómo esas regiones pertenecen al shell público. Un diseño predeterminado puede proporcionar un encabezado, una región principal y un pie de página; un diseño de documentación puede agregar una barra lateral.
El diseño puede definir el orden, los elementos contenedores semánticos, las clases contenedoras y una clase de cuerpo público. Posee la estructura externa en la que se representa el contenido, por lo que los bloques no tienen que resolver la pregunta: ¿Qué tipo de shell de página estoy dentro?
No debería existir una barra lateral de documentación porque un bloque de contenido emitió un contenedor de barra lateral. El diseño de los documentos es propietario de esa región. Los bloques colocados en su interior permanecen como contenido en lugar de convertirse secretamente en arquitectura de página.
Hay un costo: cambiar un diseño es estructural, no meramente visual. Por lo tanto, WebBlocks no elimina ni reescribe silenciosamente los espacios de página existentes cuando cambia una selección de diseño. Los espacios faltantes se pueden agregar explícitamente, mientras que los espacios adicionales se informan y conservan.
Ranura: ubicación con nombre y propiedad del contenido
Una ranura conecta la promesa estructural del diseño con una página en particular. Nombres como header, main, sidebar y footer tienen un significado que va más allá de la posición. El renderizador público puede elegir un contenedor semántico para la región y las herramientas pueden abordarlo sin adivinar dónde se encuentra en un árbol JSON.
Un espacio de página WebBlocks tiene una fuente explícita: page representa los bloques que pertenecen a esta página, shared_slot representa un árbol de bloques reutilizable compatible con el ámbito del sitio y disabled preserva la región sin representar ningún bloque dentro de ella.
Por tanto, la reutilización es una referencia más que una copia. Un encabezado compartido se puede actualizar una vez y representar en cada página que haga referencia a él. El impacto más amplio sigue siendo visible: Shared Slots tiene sus propias revisiones y flujo de trabajo de publicación.
La página consumidora todavía posee el contenedor de espacios. Un Shared Slot aporta solo el árbol de bloques interno, lo que evita que el contenido reutilizable traiga un segundo shell de página a la página que lo consume.
Bloque: la unidad de contenido
Los bloques son las unidades editoriales colocadas en una ranura. Un bloque puede representar un encabezado, texto enriquecido, imagen, navegación, galería o un diseño primitivo como una pila o una cuadrícula. Los bloques admitidos pueden contener bloques secundarios, por lo que el contenido dentro de una ranura aún puede formar un árbol.
La restricción importante es qué bloques no poseen. Un bloque no debe decidir la ruta de la página, el estado del flujo de trabajo o la capa exterior. Es propietario de su contenido, traducciones, configuraciones, relaciones y representación dentro de la región en la que se le proporcionó.
Eso mejora la validación. Un encabezado tiene un contrato diferente al de una galería. Una herramienta de automatización puede descubrir esquemas tipados en lugar de editar un documento de página sin restricciones. El renderizado y la migración pueden inspeccionar las relaciones en lugar de aplicar ingeniería inversa a un blob.
El almacenamiento relacional no es automáticamente superior a JSON. Aclara algunas reglas de integridad y migraciones al tiempo que introduce más tablas y uniones. WebBlocks acepta ese costo porque la propiedad explícita es importante para sus flujos de trabajo de automatización, localización, revisión y múltiples sitios.
Una página de documentación concreta
Considere una página de instalación en un sitio de documentación:
Page: Installation
Layout: Docs
Slot: header -> Shared Slot: Docs header
Slot: sidebar -> Shared Slot: Docs navigation
Slot: main -> Page-owned blocks
Content header
Rich text
Code
CalloutCada cambio tiene ahora un dueño natural. Cambiar /docs/installation pertenece al flujo de trabajo de enrutamiento y traducción de páginas. Agregar un riel estructural pertenece al diseño. Reemplazar la navegación de la documentación pertenece a la ranura de la barra lateral o su Shared Slot. La edición de un comando de instalación pertenece al bloque Código.
La jerarquía es útil porque indica tanto a las personas como a las herramientas a dónde pertenece un cambio.
Dónde puede fallar este modelo
Una arquitectura clara no garantiza un editor claro. Si alguien debe navegar manualmente Página -> Diseño -> Slot -> Bloque cada vez que quiere corregir una oración, el modelo se está filtrando en el flujo de trabajo. La búsqueda, los resúmenes útiles, los enlaces de edición directa y los valores predeterminados sensatos deberían permitir que las tareas rutinarias omitan capas sin borrarlas del sistema.
El modelo también puede llegar a estar sobrediseñado. Es posible que un sitio con una plantilla fija y varios campos no se beneficie de diseños configurables o árboles de espacios reutilizables. Un modelo de página tipado o un documento Markdown simple puede ser la mejor herramienta.
Un límite gana su lugar cuando absorbe un tipo de cambio sin obligar a las demás capas a fingir que también cambió.
Cuatro preguntas ayudan a comprobar si una capa se está ganando su lugar:
- ¿Tiene un tipo distinto de cambio?
- ¿Se puede validar ese cambio de forma independiente?
- ¿La frontera impide un verdadero estado inválido?
- ¿Puede la edición de rutina evitar pagar el costo total de la complejidad?
Si la respuesta a las tres primeras es no, la capa puede ser una ceremonia. Si la respuesta a la cuarta pregunta es no, la arquitectura puede ser sólida mientras que la experiencia del producto aún necesita mejorar.
Los límites son útiles cuando absorben el cambio
Page -> Layout -> Slot -> Block no se presenta como una invención nueva. Las regiones, los componentes y el contenido estructurado existen desde hace mucho tiempo en los productos CMS.
La cuestión es la propiedad explícita. Las páginas tienen identidad y flujo de trabajo propios. Los diseños poseen el caparazón. Las tragamonedas poseen una ubicación con nombre propio y una fuente de contenido. Bloquea contenido propio.
Esos límites ganan su lugar cuando puede ocurrir un cambio dentro de uno de ellos sin obligar a los demás a fingir que ellos también cambiaron.
¿Dónde se traza la línea entre la estructura de la página y el contenido en un CMS basado en bloques y qué límite causa la mayor fricción para los editores?