Extensible en Framework

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...