Extensible en Framework

  (pour les développements futurs)


L’architecture très modulaire de SPIP offre de nombreux atouts
pour étendre la mise en oeuvre 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 à plus large couverture fonctionnelle, pour ajouter de nouveaux objets éditoriaux...

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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 [1], 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 [2], 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 :


Echaffaudage des pages de l’espace privé pour les nouveaux objets, lorsqu’ils sont declares via declarer_tables_objets_sql

Pour la page de visu d’un objet exec=monobjet :
il faut et il suffit d’ecrire les 2 squelettes
- prive/objets/contenu/monobjet.html qui affiche le contenu editorial 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’edition d’un objet exec=monobjet_edit :
il faut et il suffit d’ecrire 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’ecrire le squelette de liste prive/objets/liste/monobjets.html

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

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 [3] 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 [4]), c’est un formulaire, 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 pré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 ou erreurs qui figureraient dans cette page.

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

[2Référencé dans Wikipedia http://fr.wikipedia.org/wiki/Liste_.....

[3Ce 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..

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


Liens visibles seulement pour les inscrits.

Article publié le 21 décembre 2011, et actualisé en juin 2017 Provisoire (à compléter...) .

1 Message

Répondre à cet article