Extensible en Framework

  (pour les développements futurs)

L’architecture très modulaire de SPIP offre de nombreux atouts
pour étendre la mise en œuvre progressive de SPIP, mais aussi comme base d’extension et de développement de nouveaux outils.

Ce point est particulièrement important à prendre en compte dans la perspective de projets [1] à plus large couverture fonctionnelle, pour ajouter de nouveaux objets éditoriaux...

Article publié le 21 décembre 2011, et actualisé en décembre 2021

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Attention, cette page est encore en    

L’évolution et l’extensibilité de SPIP tant pour les utilisateurs (avec les plugins tout prêts) que pour les développeurs de nouvelles fonctionnalités représente un atout d’importance pour le choix d’une architecture Web.

C’est d’ailleurs l’évolution générale des CMS [2], proposer des fonctionnalités de base, à adapter et ré-utiliser pour de nouveaux projets, évolution que l’on retrouve aujourd’hui chez Drupal (avec Symfony2, et Twig qui reprend les concepts des squelettes SPIP), Jahia ou autres, ce qui amène à considérer la recherche de CMF, ou Content Management Framework .

 L’approche Framework

Pour vous intéresser à cet aspect framework [3], citons simplement deux-trois articles portant sur la version SPIP2, en sachant que ces objectifs sont à la base de tous les développements modularisant la version SPIP3 :
- l’un ressort d’un développeur impliqué dans SPIP
- l’autre apporte le pont de vue d’un gestionnaire de système d’information suisse,
qui proposait aussi une extension OLAP,
- avec la référence ARNO* basée sur SPIP 2 utilisé comme un FrameWork !
- et dernièrement, un (vieux) résumé de compétences sur Spip2-Framework et le développement de plugins, à actualiser pour SPIP 3.

Et sans attendre, on peut s’informer de tutos pour créer un nouvel objet éditorial (en spip2 ou spip3, et encore plus simplement déjà rajouter des champs Extras en Saisie sans oublier la Fabrique...

 Spip 3 est un framework !

Pour expliciter les personnalisations restant à écrire sur un nouvel objet éditorial, à partir d’un SPIP 3 rien n’égalera à mon avis, la description reprise ci-dessous :

Échafaudage des pages de l’espace privé pour les nouveaux objets, lorsqu’ils sont déclares via declarer_tables_objets_sql

Pour la page de visu d’un objet exec=monobjet :
il faut et il suffit d’écrire les 2 squelettes
- prive/objets/contenu/monobjet.html qui affiche le contenu éditorial d’un objet champ par champ
- prive/objets/info/monobjet.html qui affiche le contenu du bloc d’information de l’objet

Pour la page d’édition d’un objet exec=monobjet_edit :
il faut et il suffit d’écrire le #FORMULAIRE_EDITER_MONOBJET, qui prend comme arguments :
- (id, id_rubrique, retour, lier_trad) si l’objet est rattache aux rubriques
- (id, retour, lier_trad) si l’objet n’est pas rattache aux rubriques

Pour la page qui liste tous les objets de ce type exec=monobjets :
il faut et il suffit d’écrire le squelette de liste prive/objets/liste/monobjets.html

Il reste donc actuellement 3 squelettes simples et le formulaire d’édition de l’objet à écrire manuellement pour disposer d’une interface complète par échafaudage.

Il est ensuite possible d’écrire ses propres squelettes pour chacune des pages ou d’un morceau de page, dans les cas particuliers

PS. Pour vous expliquer la densité synthétique de cette note, on précisera simplement qu’il s’agit de la copie in-extenso de la note de mise-à-jour du SVN public de la forge de développement [4] de SPIP !

Cette synthèse pragmatique intègre l’ensemble des facilités de développement sous SPIP :
- pour toute fonction d’affichage (lecture), c’est un squelette HTML (classique SPIP)

- pour toute pratique de mise-à-jour (CRUD [5]), c’est un formulaire [6], soit plus précisément :

  • un squelette contenant un <FORM .....><INPUT..> </FORM>, simple HTML
  • le complément en CVT, qui est un fichier PHP (de structure régénérée par la Fabrique) pour programmer les instructions de contrôle spécifique des champs.

- l’échafaudage fait allusion à la construction automatique des squelettes
par analyse de la structure de la table en base de données
- et le développeur ne rappelle même pas l’interopérabilité multi-SGBD/multi-base de SPIP !

Par expérience personnelle, il n’y a pas besoin d’être très calé en PHP pour ce faire :
il suffit de gérer CSS et HTML ; en SPIP 2 ce n’était pas la même chose !!

Gageons que des tutoriels plus détaillés ne devraient plus tarder...


Merci de nous signaler les coquilles, imprécisions ou erreurs qui figureraient dans cette page.

[1Cet article écrit en 2011 à propos de SPIP 2, ne prend pas en compte toutes les évolutions ajoutées par SPIP 3, à voir décrites de façon plus détaillée dans les articles suivants de EXTRA SPIP.

[2Comme d’ailleurs, l’un des principes de base de la POO : Programmation Orienté Objet

[3Référencé dans Wikipedia https://fr.wikipedia.org/wiki/Liste.....

[4Ce qui vous donne une haute idée de la qualité du code développé sur cette forge : ce n’est pas souvent qu’on trouve une telle qualité des commentaires chez les éditeurs, mème propriétaires..

[5Create Replace Update Delete : acronyme récapitulant toutes les opérations possibles, et nécessaires, pour pouvoir modifier des données en base !!

[6Généré automatiquement par l’usage de la Fabrique, à partir d’uen table SQL déjà existente !

[7Cet article écrit en 2011 à propos de SPIP 2, ne prend pas en compte toutes les évolutions ajoutées par SPIP 3, à voir décrites de façon plus détaillée dans les articles suivants de EXTRA SPIP.


Liens A2A visibles seulement pour les inscrits.
Liens visibles seulement pour les inscrits.

Article publié le 21 décembre 2011, et actualisé en décembre 2021 décideurs .

1 Message

Répondre à cet article