Tiens, je retrouve un vieux mail que j’avais envoyé à Lazuly et Lefayot, le 24 février 2002. À l’époque, occupé au développement de SPIP, j’avais commencé à bidouiller un outil pour – j’imaginais – ne pas rester dans les structures de base de données de SPIP. Ça s’appelait « SADE » (Système Automatisé de Développement et d’Édition), apparemment il y avait un vague bout de code sur Rezo. Si je me souviens bien, il s’agissait tout de même de livrer une structure « à la SPIP » dans un système qui permettrait de faire n’importe quoi. Oh. Évidemment c’était prétentieux et imbitable, et c’est mort né.
==========
Salut Yann et Jean-Charles,
Quelques infos sur SADE (Système Automatisé de Développement et d’Édition)... Comme j’ai réussi à endormir JC en lui présentant le système, je vous envois cette première explication.
La version en développement est visible à l’adresse : ▻http://rezo.net/~arno/sade
c’est évidemment très loin d’être complet, ni fonctionnel... Ni même optimisé, ça te pond de la requête mySQL par packs de douze.
L’idée générale :
– d’un côté, essayer de conserver, pour le rédacteur et les responsables (l’équivalent des admins de SPIP), la facilité d’utilisation de SPIP. Une fois le truc installé, on doit obtenir l’évidence et la cohérence de l’interface SPIP ;
– de l’autre, avoir une souplesse la plus grande possible pour la structure du site. C’est-à-dire que celui qui installe et gère le site devrait pouvoir réaliser quasiment n’importe quel type de site de contenu. C’est la différence fondamentale avec SPIP.
Principe des objets et des éléments
–-------
Lorsqu’on définit son site, on n’a pas une structure imposée (comme SPIP et autres nukeries), il faut dire ce qu’il y aura dans son site. La base de ce système est celui d’objets constitués d’éléments. Dans l’interface actuelle, c’est dans "Structure et droits". (À terme, je prévois une interface d’upload de structures "toutes faites".)
Il faut créer un objet. Un "objet" est une notion éditoriale, et non technique. Par exemple, l’objet "Rubriques", "Articles" (façon SPIP), ou bien "Film", "Personne"...
Une fois un objet créé, il faut définir de quoi il se compose, c’est-à-dire donner les éléments constitutifs. Par exemple, pour l’objet "Articles", les éléments :
– surtitre
– titre
– soustitre
– date
– chapeau
– logo
– texte
– ps
– grand_logo
Chaque élément est d’un type particulier, ce qui permettra de fabriquer l’interface graphique pour les gérer. "Une ligne" pour un texte d’une ligne (surtitre, titre...), "un paragraphe" (pour le chapeau), "texte long" (pour le texte), "logo" pour un logo (c’est-à-dire avec gestion du survol), "url", "email", etc.
Avec la liste des éléments, on trouve :
– une flèche verte, qui permet de modifier l’ordre des éléments (le surtitre doit être avant le titre, donc si on l’a créé après, on peut le faire remonter dans l’ordre) ;
– une petite étoile jaune, qui permet de définir quel est l’élément principal de l’objet. Généralement, on l’attribue au "Titre" de l’objet. Unique utilité : dans la navigation de l’interface privée, c’est cet élément principal qui sera utilisé pour la navigation ("lire l’article ’Mon premier article’")
Le second truc très important des objets, ce sont les liens de dépendance. C’est plutôt logique : une rubrique dépend d’une autre rubrique, un article dépend d’une rubrique, etc. Avec l’option qu’un lien peut être obligatoire, et/ou unique (par exemple, façon SPIP, une rubrique dépend d’une unique rubrique, mais ce lien n’est pas obligatoire, car certaines rubriques peuvent être des "entrées" dans le site ; en revanche, un article dépent obligatoirement d’une unique rubrique...). La particularité, c’est qu’il s’agit d’un lien de dépendance, et non d’un lien direct dans les deux sens : c’est bien un article qui dépend d’une rubrique, et non le contraire ; c’est ce qui permettra, dans l’espace privé, de faire une interface logique (on pourra créer un article depuis une rubrique, mais non l’inverse ; l’inverse, ce sera qu’on peut sélectionner une rubrique depuis un article).
Toujours dans ces liens, il est possible de faire un lien d’un objet à un autre, en fonction d’un troisième objet. Utilisation rare. Par exemple : je fais image movie database : je fais un objet "Films", un objet "Personnes", et un objet "Métiers du cinéma". Je fabrique, dans "Films", le lien suivant : Film dépend de Personnes en fonction de Métiers. Ainsi je peux indiquer dans tel film que "Jess Franco" est "réalisateur" du film, qu’il est "acteur" du même film...
Gestion des droits
–-------
De plus, il devrait y avoir une gestion des droits très précise. Dans "Gérer les droits et les statuts", on peut créer :
– des statuts des participants (admin, responsable, rédacteur...),
– des statuts des documents (en cours de rédaction, proposé, publié, refusé...). Et à cet endroit, on définit les concordances par défaut de ces deux types de statuts. Par exemple, un "rédacteur" peut créer, modifier ses propres articles, mais pas quand ils sont publiés, etc.
Ensuite, pour chaque objet précis, on peut modifier et affiner ces droits. Par exemple, les "rédacteurs" ne peuvent pas du tout toucher aux "rubriques".
*******
Une fois cette structure définie, on peut passer à "Naviguer et rédiger", qui est l’interface de rédaction similaire à celle de SPIP, mais cette fois-ci identique pour chaque objet, en fonction des éléments configurés précédemment. Pour l’instant, la version actuelle permet de créer des "documents", mais pas de lier.
–> Par "document", j’entends un nouvel élément sur le modèle d’un objet. Par exemple, un nouvel article du type de l’objet "Articles".
Gros manque pour l’instant, ça ne gère pas les liens entre les documents…
******
Enfin, pour la partie publique, même système de squelettes, avec boucles et pseudo-tags, comme SPIP. Sans doute un poil plus élaboré...
Ah oui : je prévois également un générateur automatique de squelettes par défaut, histoire de pouvoir commencer son site sans douleur...
***************
***************
Enfin, la plus grosse différence de SADE avec SPIP et autres nukeries, c’est que la base de données n’a pas du tout la même structure que la structure éditoriale. Il n’existe pas une nouvelle table pour chaque objet (pas de "spip_articles" pour gérer les ARTICLES...) ni de nouvelle colonne de table pour chaque élément (pas d’entrée "surtitre" dans un "spip_articles").
Il y a :
– sade_objets où l’on stocke "ARTICLES", "RUBRIQUES"..., c’est-à-dire la définition générale des objets ;
– sade_elements où l’on stocke tous les éléments des objets ; évidemment, chaque "élément" dépend d’un id_objet de sade_objets, pour savoir qu’il s’agit du TITRE lié à ARTICLES, ou du TITRE lié à RUBRIQUES ;
– sade_liens_objets où l’on stocke les liens de dépendance entre les objets.
Ces trois tables gèrent donc la structure du site. Quand j’ajoute un objet "FILMS", je ne créé donc pas une nouvelle table "sade_films", je me contente d’ajouter une ligne "FILMS" dans sade_objets, puis de définir ses éléments et ses liens dans les deux autres tables.
Les tables : sade_statut_doc, sade_statut_redac, sade_lien_statut_defaut, sade_lien_statut_objet... définissent la gestion des droits.
Le stockage de l’information éditoriale, elle, se fait dans les tables :
– sade_documents table qui ne contient pas beaucoup d’informations, presque uniquement un id_document associé à un id_objet (j’ai créé un nouveau document associé à l’objet ARTICLES) ;
– sade_contenus c’est là qu’est réellement stockée l’information éditoriale (dans un champ "long text"). Il y a un id_contenu différent pour chaque élément du document. Donc c’est lié à un id_document et à un id_element (ceci est le contenu du titre du document) ; histoire d’optimiser les requêtes, je stocke l’élément déduit : id_objet.
– sade_liens c’est l’équivalent du précédent, mais pour la gestion des liens de dépendance. Là, évidemment, je ne stocke plus des id_objet (parent, enfant...) comme dans sade_liens_objets, mais directement des id_document (le document-article tant dépend du document-rubrique tant).
L’avantage de cette méthode, c’est :
– que la structure de la base est invariable. On se contente d’ajouter des lignes, et non de créer des tables et des colonnes pour chaque type d’objet ;
– que certaines opérations seront très simples à implémenter (genre l’indexation du moteur de recherche sera vachement souple et puissance) ;
– qu’on ne dépend absolument plus des noms de objets et des éléments (si mon "ARTICLES" se transforme en "ITEMS", on s’en fout, on travaille sur les id_objet).
Evidemment, sur le fait qu’on peut construire sa propre structure de site, les avantages sont énormes :
– personne ne demandera à ce qu’on lui ajoute tel "champ" dans les articles et autres,
– la critique "on ne peut pas ajouter ses propres modules" sera largement invalidée par le fait que la plupart des modules deviennent totalement inutiles (il suffit de faire la structure de site qui va bien) ;
– absolument tout se développe de manière unique. Il n’y a plus à prévoir des machins exotiques pour les rubriques, d’autres pour les brèves, se demander s’il faut un logo pour les types de mots-clés... c’est le webmestre qui définit sa structure, point.
Inconvénients :
– pour l’instant, ça te pond de la requête mySQL au kilomètre ; j’ai déjà beaucoup d’idées pour optimiser à mort, m’enfin rien ne presse ;
– une fois optimisées, les requêtes vont avoir une tronche terrible ;
– découlant des deux remarques précédentes : est-ce que ça tiendra lacharge ?
– comme tous les objets sont gérés de manière identique, il va falloir trouver toutes les méthodes permettant de retrouver une interface graphique claire et évidente comme SPIP ; ça, c’est pas gagné, mais je crois qu’il y a moyen de plutôt bien s’en sortir, même si on n’arrivera jamais à ce niveau d’intégration ;
– puisque c’est très souple, on va se bouffer des tonnes de sites mal branlés ! C’est l’un des gros avantages de SPIP : comme c’est figé, les sites sont forcément bien structurés, avec une navigation forcément logique. A partir du moment où l’on peut réaliser n’importe quoi, on va avoir des sites totalement imbitables (et comme toujours : c’est la faute au programme :-))
******
Bon, c’est juste un tout début, hein. Faut beaucoup d’imagination pour l’instant :-))
ARNO*
