SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

286 Plugins, 197 contribuciones sur SPIP-Zone, 284 visitantes en este momento

Portada del sitio > Squelettes > Outils pour squelettes > Zpip > Modelo de esqueleto reutilizable

Modelo de esqueleto reutilizable

17 de noviembre de 2009 – por Martin Gaitan – commentaires

Todas las versiones de este artículo: [Español] [français]

4 votos

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:

  1. <div id=’entete’> </div>
  2.  
  3. <div id=’contenu’>
  4.  
  5. </div>
  6.  
  7. </div id=’navigation’>
  8.  
  9. </div>
  10.  
  11. <div id=’pied’> </div>

Descargar

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 :

  1. <body class="page_#ENV{type}">
  2.  
  3. <div id="page">
  4. [(#REM) Cabecera + titulo ]
  5. <div id='bloc-haut'>
  6. <div id="entete">
  7. <INCLURE{fond=inc/entete}{id_rubrique}>
  8. </div>
  9. <INCLURE{fond=inc/barre-nav}{id_rubrique}>
  10. </div>
  11.  
  12. <div id='bloc-central'>
  13. [(#REM) Contenido principal : contenido del articulo]
  14.  
  15. <div class="hfeed" id="conteneur">
  16. <div class="hentry" id="contenu">
  17. [(#REM) Llamar al fond de contenido ]
  18. <INCLURE{fond=contenu/#ENV{type}}{env}>
  19. </div><!--#contenu-->
  20. </div><!--#conteneur-->
  21.  
  22. [(#REM) Menú de navegación ]
  23. <div id="navigation">
  24. <INCLURE{fond=navigation/#ENV{type}}{env}>
  25. </div><!--#navigation-->
  26.  
  27. [(#REM) Menu de navigación lateral ]
  28. <div id="extra">
  29. <INCLURE{fond=extra/#ENV{type}}{env}>
  30. </div><!--#extra-->
  31. <div class='nettoyeur'></div>
  32. </div><!-- #bloc-central-->
  33.  
  34. [(#REM) Pie de página ]
  35. <div id="bloc-bas">
  36. <div id="pied">
  37. <INCLURE{fond=inc/pied}>
  38. </div>
  39. </div>
  40. </div><!--#page-->
  41. </body>

Descargar

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:
  1. <BOUCLE_article_principal(ARTICLES) {id_article}>
  2.  
  3. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  4.  
  5. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="#LANG" lang="#LANG" dir="#LANG_DIR">
  6.  
  7. <head>
  8. <title>[(#TITRE|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]</title>[
  9. <meta name="description" content="(#INTRODUCTION{150}|attribut_html)" />
  10. ]<B_URLMOT>
  11. <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>" />
  12. </B_URLMOT><B_URLAUTEURS>
  13.  
  14. <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>" />
  15.  
  16. </B_URLAUTEURS><INCLURE{fond=inc/head}>
  17.  
  18. </head>
  19.  
  20. <INCLURE{fond=body}{env}{type=article}{id_rubrique}>
  21.  
  22. </html>
  23.  
  24. </BOUCLE_article_principal>

Descargar

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.

Dernière modification de cette page le 27 de diciembre de 2009

Volver arriba

Sus comentarios

  • El 20 de septiembre de 2014 a 09:13, por alf En respuesta a: Modelo de esqueleto reutilizable

    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.

    Responder a este mensaje

  • El 14 de mayo de 2012 a 21:23, por Juan En respuesta a: Modelo de esqueleto reutilizable

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

    Muchas gracias.

    Responder a este mensaje

Comentar este artículo

¿Quién es usted?
  • [Conectarse]

Para mostrar su avatar con su mensaje, guárdelo en gravatar.com (gratuit et indolore) y no olvide indicar su dirección de correo electrónico aquí.

Añada aquí su comentario Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Añadir un documento

Volver arriba

Hablando de eso...

  • (fr) noiZetier v2

    9 novembre 2012 – 36 commentaires

    Le noiZetier offre une interface d’administration permettant d’insérer au choix des éléments modulaires de squelettes (noisettes) et de les ajouter ainsi à ses squelettes. Compatibilité La version 2 du noizetier fonctionne sous SPIP 3. Elle est (...)

  • (fr) cirr : plugin « rédacteur restreint »

    29 octobre 2010 – 60 commentaires

    Ce plugin « cirr : rédacteur restreint » permet d’affecter des rubriques aux rédacteurs et modifie les droits afin qu’un rédacteur restreint (ou un administrateur restreint) voit dans l’espace privé uniquement les rubriques qui lui sont affectées (et leur (...)

  • (fr) Un retour d’expérience d’utilisation de Formidable

    26 octobre – commentaires

    Il s’agissait de créer un formulaire d’inscription à un évènement modérer les inscriptions dans le privé publier les inscriptions dans le public Nous avons discuté de cette présentation lors de l’apéro SPIP du 15 février 2016 à la Cantine (...)

  • (fr) Métas +

    3 décembre – 14 commentaires

    Améliorez l’indexation de vos articles dans les moteurs et leur affichage sur les réseaux sociaux grâce aux métadonnées Dublin Core, Open Graph et Twitter Card. Installation Activer le plugin dans le menu dédié. Dans le panel de configuration, (...)

  • (fr) Adaptive Images

    15 novembre 2013 – 69 commentaires

    Un plugin pour permettre aux sites responsive d’adapter automatiquement les images de la page à l’écran de consultation. Adaptive Images, que l’on pourrait traduire par Images adaptatives, désigne la pratique qui vise à adapter les taille, (...)