From: ARNO* Subject: [Spip] Quelques propositions de base Newsgroups: gmane.comp.web.spip.devel Date: 2000-01-29 20:38:55 GMT
Salut tout le monde,
Voici quelques idées que j’ai notées pour relancer SPIP.
Organisation du boulot
La façon de bosser jusqu’ici (chacun son propre code pour son propre site) a permis d’avancer sur notre maîtrise technique, mais on aboutit à une impasse, car on n’arrive pas ensuite à fusionner les travaux. Il faut qu’on trouve une autre méthode à partir de maintenant.
Techniquement, on a chacun fait des trucs complémentaires :
- Laz a fait une interface de mise en ligne, et un système de gestion des autorisations ;
- Fil et moi avons trouvé une méthode pour gérer un site à structure complexe.
Je propose donc qu’avant de commencer la moindre ligne de code, on définisse « sur le papier » très précisemment ce vers quoi on veut aller, définir très précidemment le produit. Ensuite une réunion tous ensemble pour valider les choix. Ensuite seulement on pourra attaquer le code.
Caractéristiques de spip
– Système de création et de gestion de sites Web
– Interface entièrement en ligne (WEB)
– Travail collaboratif
– Sites à structure complexe :
ex : l’Ornitho a une structure très complexe, à la fois chronologique —par numéros— et thématique —type d’articles—, plus, me semble-t-il, les sujets « par auteur » ; c’est le type même de structure ingérable à la main que SPIP doit permettre facilement
Le système doit être très simple à installer et à utiliser. Grosso modo, un dossier à installer sur son site, et on peut directement commencer à travailler sans presque lire la documentation. Il faut que n’importe qui, sans la moindre connaissance technique (sauf installer un dossier par ftp...) puisse commencer à créer un site, sans installer de packages, recompiler quoi que ce soit, etc.
Le site doit pouvoir être très adaptable à n’importe quelle situation. Bien sûr, pour personnaliser le site, la doc sera indispensable.
Le système doit être « dans un dossier », facilement intégrable à un site déjà existant.
Tout cela doit (bien sûr) être en GPL.
Choix techniques
Ça, on doit se mettre d’accord absolument avant de commencer... C’est la base même.
– Interface PHP3 ;
– documents gérés par mySQL (ça m’a l’air d’être plus pratique, souple et puissant que de simuler une base de donnée en mode texte comme on le fait, Laz et moi) [1] ;
– pages dynamiques ou pré-générées ? Là j’ai pas d’opinion tranchée. Ou alors on peut faire un mélange des deux, c’est sans doute avec ça qu’on aura les résultats les plus puissants.
Important : architecture modulaire.
Chaque fonction de SPIP doit être sur un page PHP3 séparée, et clairement définie. À mon avis, y’a que comme ça qu’on pourra désormais collaborer : quand chacun a le temps, il annonce qu’il se charge de tel module, et peut le faire évoluer. Cela permettra également au produit d’évoluer par la suite. Si c’est bien foutu, on devrait réussir même à ajouter des modules par la suite (genre : export PDF, cahier mensuel, envoit par mailing-list, etc.) sans perturber les autres modules.
La version de base serait livrée avec 2 bases de données pré-installées : une base des articles et une base des auteurs. Ainsi le site serait prêt à fonctionner dès le chargement du dossier.
les modules
Par module, j’entends deux choses :
- chaque fonction du site est clairement identifiée ;
- chaque module est sur une page PHP3 indépendante (pour faciliter l’organisation du travail).
Gestion des autorisations
3 niveaux d’autorisation :
- Administrateur
- Le seul à pouvoir tout faire. Notamment modifier la structure de la base de donnée, l’interface graphique, etc.
- Membre (articles acceptés « a priori »)
- Peut ajouter des rubriques au site et gérer la structure du site.
- Participe aux votes de validation des articles soumis par les "invités"
- Reçoit les courriers de la liste de discussion interne du site
- Peut modifier les anciens articles directement.
- Auteur invité
- Peut proposer des articles (qui devront être validés par les membres)
Je propose que les auteurs invités aient leurs propres code d’accès : lorsqu’ils veulent proposer leur premier article, ils doivent remplir une fiche d’identité contenant notamment leur adresse email. Alors ils recoivent par mail un code d’accès personnalisé. De cette façon l’auteur est au moins identifié par une adresse mail valide. Dans la base « articles », chaque article contiendrait un champ de validation (genre : « pour:2 ;contre:3 » ou « veto » ou « valide ») ; les règles de validation (majorité, unanimité, un seul vote d’acceptation, etc.) seraient libres, définissables par interface graphique.
Faut-il prévoir un statut spécial pour des « Contributions libres », sans aucun enregistrement ?
Création des articles
L’interface Web de Laz.
Avec « raccourcis SPIP » (note de base de page, intertitres, etc.).
Première correction typographique. Une solution que j’utilise sous TeX : la version stockée est « simplifiée », c’est-à-dire que tous les « blancs » sont supprimés (supprime les blancs doubles, supprime même les blancs avant les deux points, etc.) ce qui permet d’éviter les conflits dans les corrections de typographique (ajouter des blancs insécables alors qu’ils y sont déjà, etc.). La version stockée est donc, dans l’absolu, incorrecte typographiquement, mais beaucoup plus facilement éditable. Ensuite, lors de la génération du site, les quelques blancs nécessaires sont ajoutés.
Y’a-t-il possibilité de correction orthographique automatisée ?
L’auteur choisit lui-même la(les) rubrique(s) où installer l’article. En réalité, il doit remplir tous les champs liés à l’article, ce qui permet ensuite de gérer n’importe quelle organisation du site (par auteur, par date, par sujet traité, etc.).
Gestion des champs des bases de données
Le site serait structuré autour de plusieurs bases de données. Par défaut : articles & auteurs. On peut imaginer des bases supplémentaires pour n’importe quel usage : par exemple des listes thématiques de liens Web, des cartographies, des listes de dates, etc. Je ne connais pas bien mySQL, mais je suppose que l’utilisation de différentes bases de données permet d’enrichir des croisements d’info.
L’admin doit donc pouvoir personnaliser ou créer des bases. Par exemple : ajouter dans « articles » un « sur-titre", un champ « sujet traité".
Dans « auteurs" il peut ajouter « photo de l’auteur », « date de naissance », etc. N’importe quoi, donc. Cette interface graphique de base de donnée pourrait ressembler à l’UngiTrombi de Gilles Maire.
Si on fait ça bien, le site peut être de n’importe quelle nature, avec le même moteur. Par exemple, j’utiliserais SPIP pour créer une base de donnée cinéma sans problème (on aurait donc des liens dans tous les sens, plus une hiérarchie thématique). Les problèmes que soulève Fil pourraient être résolus uniquement en utilisant de manière personnalisée la structure de la BdD (par exemple, ajouter dans la base « articles » un champ « Cahier », et ainsi on pourrait ajouter à la structure hiérarchique une structure en cahiers).
Gestion de la structure du site
Là, c’est très différent du module précédent (gestion des champs des BdD), il s’agit simplement d’organiser la structure du site (déplacer un article, créer une nouvelle rubrique, etc).
Notez bien : ça me semble très ardu de réussir là une interface graphique pour gérer « simplement » quelque chose d’aussi complexe. Car l’interface doit pouvoir s’adapter à n’importe quelle structure du site, selon des champs et des base de données qu’on n’aurait pas prévu à l’origine.
Le tout avec une interface graphique Web. Hum... Java et glisser-déposer ?
Gestion de l’interface graphique
Au départ, c’est tout simplement un choix entre plusieurs « thèmes » (skins) préinstallés, histoire de pouvoir commencer rapidement le site.
Ensuite, c’est plus complexe, il faut pouvoir paramétrer facilement sa propre interface, avec ses propres « champs » (sachant qu’on peut en créer directement dans la base de données). Là encore, c’est un point délicat.
Ça peut être un double système :
- le graphiste fabrique les pages en HTML, avec quelques champs de pseudo-HTML ;
- une fois sur le Web, ces champs « pseudo-HTML » peuvent être personnalisés (présentation des différents « champs » des bases de données.)
Il faut pouvoir gérer deux types d’appels :
- les appels simples (afficher le titre de l’article, le nom de l’auteur)
- les appels récursifs (la liste des articles traitant du même thème...).
Prévoir peut-être des ordres conditionnels : afficher uniquement si une info existe, sinon autre chose, etc.
Génération du site
Facile : c’est la page où on appuie sur un bouton, et le site est créé. :-)
Doit gérer :
- la seconde correction typographique (remettre les blancs insécables) ;
- les listes de type « quoi de neuf », classement thématique, etc.
Module de communication
Module(s) permettant les échanges entre les membres.
Principalement :
- gestion des votes de validation pour les articles proposés par des invités.
- Interface mail-Web. -> MODULE DE VALIDATION
On peut imaginer : chaque fois qu’un « invité » poste un article, chaque membre reçoit un mail avec un adresse Web à visiter. Là il peut lire l’article, qui est suivi de : bouton « pour », bouton « contre », champ de texte « commentaire ».
Options à prévoir
Là, je sais pas : est-ce qu’il faut les prévoir dès le début ? Ou bien est-ce qu’on peut imaginer une programmation du « noyau » principal suffisamment souple pour que l’ajout de nouvelles fonctions soit facile (genre « plug-in ») ?
- Versions HTML imprimables (genre Menteur/Scarabée) pour chaque article ;
- Versions multilingues ;
- Cahiers PDF ;
- Création d’images typographiques (titres, intertitres avec des « belles » polices - transformer une base genre « H1 » en GIF avec une police choisie et quelques effets) ;
- Gestion d’interfaces un poil chiadées : menus déroulants, image-map (le tout en server-site, bien entendu).
- Interface pour listes de diffusion, forums, moteur de recherche, etc.
- Interface vers Eternam (quand ça existera...).
Voilà pour le moment, c’est tout ce que je vois... Ce ne sont que des propositions, hein. :-)
Amicalement,
ARNO*