Modelo de esqueleto reutilizable

Hacia una estructura modelo para promover la reutilización, el intercambio y la mejora de los conocimientos colectivos. Continuación de la reflexión del artículo « L’après SPIP 2.0 ».

Los esqueletos dist de SPIP 1.9.x y 2.0

Los esqueletos dist de SPIP 1.9.x y 2.0 son fáciles de comprender ya que se basan en un esqueleto por objeto (artículo, sección, etc.), asignando una presentación para cada uno. De esta manera los artículo son mostrados a través de article.html, las secciones via rubrique.html, y así sucesivamente.

Es fácil encontrar el esqueleto que muestra determinada información y copiarlo dentro de la carpeta squelettes/ para personalizarlo (modificar el contenido de la columna de navegación, el orden de presentación de las secciones ...).

Pero esta técnica, alentada por la documentación de SPIP y por los esqueletos por defecto de SPIP, conduce a malas prácticas que pueden ocasionar nefastos resultados.

Una duplicación de código sin fin

La primer negligencia es la duplicación lisa y llana de código. Así, a veces sólo para cambiar un detalle (por ejemplo, el orden de presentación de artículos en el menú de navegación), nos vemos obligados a repetir todo el esqueleto de la página donde se encuentra el menú.

La duplicación de código no es un problema técnico en sí mismo : todo el mundo, o casi, sabe copiar y pegar. Pero es altamente contraproducente en términos de mantenimiento.

Lo que sucede cuando se repite el mismo código numerosas veces es que al momento de una actualización, un bucle de la dist pudo haber sido corregido o mejorado. ¿Y qué se debe hacer entonces ? Simplemente repasar una por una todas las duplicaciones para actualizarlas a la nueva versión. Pérdida de tiempo y de calidad (una operación manual realizada N veces está estadísticamente propensa a error).

Poco código compartido

En la organización y el diseño de los esqueletos dist mostrado en el ejemplo, cada uno añade una funcionalidad adicional directamente en sus esqueletos personalizados. Por supuesto, todo el mundo evita reinventar la rueda, y nadie duda en copiar y pegar este bucle de SPIP-Contrib, aquel que se encuentra codificado en otro proyecto, o cualquier otro recuperado por la lectura del esqueleto de un sitio en línea.

Pero nunca es el mismo componente que el que se reutiliza. Sólo es una copia de un componente ya hecho en alguna parte. Y si alguien lo mejora en favor de un sitio, nadie más se beneficiará.

Todo el mundo lo hace de nuevo en su rincón

De repente, todo el mundo hizo lo mismo en su rincón. E incluso varias veces. Corrección de errores, cambios funcionales, complementos, etc ...

Simplemente porque la arquitectura inicial propuesta por SPIP no es adecuada para la máxima reutilización, y todavía continúa propagandose por imitación.

Cada actualización de la versión es un caso único

Cada sitio tiene con su propio esqueleto, debe ser tratado como un caso aislado durante las actualizaciones de versión. Con el resultado de que muchos sitios, por distintas incompatibilidades, no se podrán actualizar.

Un nuevo modelo

Con SPIP 2.0 llegó una serie de herramientas para abrir un nuevo camino que vamos a tratar de esbozar aquí.

Separa el diseño de los esqueletos restantes

El « layout » es la estructura general de la página HTML, los grandes bloques que la conforman. Un esquema simple podría ser :

<div id=’entete’>  </div>

<div id=’contenu’>

</div>

</div id=’navigation’>

</div>

<div id=’pied’> </div>

La misma presentación puede tener múltiples « pieles ». Sin embargo, ningún layout puede adjudicarse la generalización completa ya que debería ser capaz de cambiar la organización estructural del sitio. Pero teniendo en cuenta los defectos del método copiar-pegar, sería deseable que no se repita más código entre distintos esqueletos.

Dentro de la dist, la organización de la página está escrita en cada esqueleto. Cambiar esta organización implica la duplicación ipso-facto de todos los esqueletos de la dist. Eso es lo que queremos evitar.

Por eso proponemos que la estructura de la página se defina en un sólo sitio, un esqueleto llamado body.html, que determina el cuerpo y sus contenidos, incluyendo una llamada para cada bloque estructural.

Aquí un ejemplo de body.html para una estructura de página la dist de SPIP :

<body class="page_#ENV{type}">

	<div id="page">
		[(#REM) Cabecera + titulo ]
		<div id='bloc-haut'>
			<div id="entete">
				<INCLURE{fond=inc/entete}{id_rubrique}>
			</div>
                  	<INCLURE{fond=inc/barre-nav}{id_rubrique}>
            	</div>

		<div id='bloc-central'>
			[(#REM) Contenido principal : contenido del articulo]

			<div class="hfeed" id="conteneur">
				<div class="hentry" id="contenu">
					[(#REM) Llamar al fond de contenido ]
                          		<INCLURE{fond=contenu/#ENV{type}}{env}>
				</div><!--#contenu-->
			</div><!--#conteneur-->

			[(#REM) Menú de navegación ]
			<div id="navigation">
				<INCLURE{fond=navigation/#ENV{type}}{env}>
          		</div><!--#navigation-->

	          	[(#REM) Menu de navigación lateral ]
        	  	<div id="extra">
				<INCLURE{fond=extra/#ENV{type}}{env}>
			</div><!--#extra-->
			<div class='nettoyeur'></div>
		</div><!-- #bloc-central-->

		[(#REM) Pie de página ]
		<div id="bloc-bas">
			<div id="pied">
				<INCLURE{fond=inc/pied}>
			</div>
		</div>
	</div><!--#page-->
</body> 

Esta propuesta lleva varios comentarios :

  • Se proponen 3 bloques funcionales comunes : la cabecera, el pie, y la barra de navegación. Los otros bloques están en función al tipo de objeto que se pretende mostrar.
  • En cuanto a la organización de los otros bloques, proponemos que se adopte una organización de carpetas similar a la página, que divide las piezas de cada tipo en sub carpetas con el mismo nombre que los bloques. Por ejemplo, para la página article.html tenemos :
    • contenu/article.html
    • navigation/article.html
    • extra/article.html
  • De esta manera el esqueleto principal está muy simplificado
    Un esquelto article.html podría ser, por ejemplo, el siguiente :
 <BOUCLE_article_principal(ARTICLES) {id_article}>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="#LANG" lang="#LANG" dir="#LANG_DIR">

<head>
<title>[(#TITRE|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]</title>[
<meta name="description" content="(#INTRODUCTION{150}|attribut_html)" />
]<B_URLMOT>
<link rel="alternate" type="application/rss+xml" title="<:titre_page_mots_tous:>" href="#URL_PAGE{backend}<BOUCLE_URLMOT(MOTS){id_article}>&amp;id_mot[]=#ID_MOT</BOUCLE_URLMOT>" />
</B_URLMOT><B_URLAUTEURS>

<link rel="alternate" type="application/rss+xml" title="<:icone_auteurs:>" href="#URL_PAGE{backend}<BOUCLE_URLAUTEURS(AUTEURS){id_article}>&amp;id_auteur[]=#ID_AUTEUR</BOUCLE_URLAUTEURS>" />

</B_URLAUTEURS><INCLURE{fond=inc/head}>

</head>

      <INCLURE{fond=body}{env}{type=article}{id_rubrique}>

</html>

</BOUCLE_article_principal>

Ya podemos ver que esta organización permite cambiar de forma independiente el layout, el contenido y las columnas de navegación y extras para cada tipo de objeto.

Variación de la composición de los contenidos de un tipo de objeto

Se espera que el contenido se muestra de manera diferente, con un funcionamiento diferente según el caso. Ejemplo típico : esta sección listará todos sus contenidos, mientras que las otras no mostrarán el texto de inicio y las subsecciones deben ser accesibles por su menú lateral de navegación. ¿Hay una respuesta simple a esta necesidad ?

Las soluciones basadas en palabras clave o esqueleto particularizados del tipo rubrique-XX.html son desastrosas en la práctica, ya que quedan en manos de terceros no involucrados en la concepción del sitio .

El plugin Compositions mejora esto. Permite variar la composición, objeto por objeto. El esqueleto puede contener en sí mismo varias variantes, pero también los plugins puede proporcionar composiciones listas para usar. Por ejemplo, el plugin de calendario podría proporcionar una composición contenu/rubrique-agenda.html para presentar el contenido de una sección agenda, que será reutilizable en todos los sitios construídos con el mismo modelo de esqueletos.

Este mecanismo permite compartir código de composiciones entre objetos, o incluir composiciones a través plugins para su reutilización.

Temas

El modelo de estructura de esqueleto mencionado aquí también puede definir un mecanismo de temas, incluyendo :

  • una o más hojas de estilo CSS
  • un esqueleto de imágenes decorativas
  • un eventual body para definir un layout específico para un tema.

Un conjunto de convenciones de nombres para los selectores CSS se propone permitir a los temas funcionar de la misma manera en todos los esqueletos que se organicen de acuerdo con el modelo descrito aquí.

Un selector de temas

El tema puede ubicarse en el directorio themes/ en la raíz de SPIP, y será manejado únicamente por un selector de temas, o ubicarse en el directorio plugins/ y activarse simplemente desde la gestión de plugins.

Todos los temas tienen el mismo prefix para permitir que sólo uno a la vez pueda ser activado desde la administración de plugins. Este prefijo será el que use también el administrador de temas, de manera de prohibir la activación de un tema como plugin si está activado el Administrador de Temas.

En camino !

Gran parte de los mecanismos propuestos en este artículo se basan en la posibilidad de inclusiones con {env}, es decir, sin tener que explicitar los parámetros a pasar. Esta mejora se introdujo en SPIP 2.

Esperamos que esta propuesta de funcionamiento permita compartir bloques de esqueletos de forma centralizada y como composiciones.

Esta puesta en común de código conducirá, probablemente, a mutualizar los esfuerzos y permitirá simplificar el mantenimiento y la evolución de los sitios.

El esqueleto Zpip es una aplicación de este modelo.

Discussion

2 discussions

  • es la base de los plugins sarkaspip, zpip, spipr (spipr-dist, spipr-blog...). lo lioso es encontrar el funcionamiento de los diversos plugins que utilizan este sistema. Hay documentación, pero no está muy bien organizada y no es completa.

    Répondre à ce message

  • Muy interesante este artículo, pero un poco lioso. Me lo tengo que estudiar con más detenimiento.

    Muchas gracias.

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom