Spip est un framework pour le développement d’applications web.
Facile à dire mais qu’est ce que ça veut dire au juste ? Et qu’est -ce que ça implique lors du développement et de l’utilisation d’outils et plugins ?
(Avec des morceaux d’irc dedans)
E-commerce : spip vs prestashop
PrestaShop est une application permettant de créer une boutique en ligne dans le but de réaliser du commerce électronique. Peut on faire l’équivalent en SPIP ?
Certainement, mais le domaine du e-commerce, dans sa globalité, est ÉNORME. Le nombre de trucs à gérer est énorme, et doublement énorme si on doit gérer une liaison/synchronisation avec un logiciel métier, ERP, stocks, etc.
Donc on est pas prêt d’avoir un truc aussi énorme vu que, à moins d’un passionné qui ne comptera pas ses heures, personne ne financera jamais ça…
En revanche, on peut petit à petit ajouter des fonctionnalités module par module, aux plugins déjà existants, si on développe bien sur une base de « framework » et non pas sur une base de solution tout-en-un.
Le développement doit donc être collaboratif car le tout, impérativement, est de toujours faire attention à ce que chaque module ait des points d’entrées pour être modifié par un autre truc plus tard.
Structure des données : Spip vs Drupal
Drupal n’a que des Nodes, et les champs particuliers à chaque sorte d’objet sont ailleurs : le Node est le truc central, et ensuite ya des sous-tables liées qui définissent des champs particuliers pour tel ou tel type de node. Du coup ça fait des jointures de malade, notamment pour la recherche / filtrage.
Avec SPIP, au contraire, un objet représentant un contenu a peu ou prou tous les champs importants dans la même table au même endroit et donc ça fait une requête toute simple.
Par contre, de ce fait il y a dans SPIP, nombre d’objets qui partagent des éléments communs. Par exemple, les champs TEXTE et DESCRIPTIF sont partagés par les articles, breves, forums, motcle etc...
Création d’objets : Forums vs Tickets
Forums et tickets ont des structures en grande partie similaires, des fonctionnements voisins, mais des sémantiques différentes, nécessitant pour certains aspects une UI différente, çad des squelettes, des chaines de langues, des autorisations et un workflow en partie différents.
Contrairement aux forums, un ticket peut exister indépendamment de tout autre objet SPIP.
Les forums ne le peuvent pas, ils doivent obligatoirement qualifier un objet, et même ils sont prévus pour former des enfilades (id_thread). Mais un ticket peut *aussi* porter sur un autre objet pré-existant. Et même, un ticket peut aussi porter sur un ticket, ce qui permet aussi de faire un thread, comme avec les forums.
La différence est donc maigre, mais le choix a tout de même été de faire 2 objets entièrement différents.
Une autre solution aurait été d’utiliser les forums, éventuellement en leur ajoutant un ou des champs et surtout en modifiant leur présentation et workflow.
Faire cohabiter les forums d’origine et les forums modifiés en tickets aurait alors nécessité d’adapter la présentation et le fonctionnement selon le contexte.
Mais ça ça doit pas être rigolo : adapter le html, adapter les chaînes de langues, adapter les autorisations...
Quelques liens
- sur wikipedia
- sur SPIP Blog
- sur SPIP pour les nuls
- chez Arno* et Diala