[spip-dev] Extentions a SPIP

ou enfin jouer le jeu spip à fond et étendre ses ressources

Oui, à fond !

Un de nos développeurs s'est lancé dans l'aventure avec un certain
succès puisqu'il a crée une première version fonctionnelle d'une
boucle AGENDA et de la balise formulaire #FORMULAIRE_AGENDA
associée. le résultat est encore très basique, mais comme
démonstrateur c'est largement suffisant.

Si y'a moyen de tester ça en ligne, ou même d'avoir le code, ça
m'intéresse au plus haut point, puisque je voulais moi aussi me lancer
dans ce chantier.

C'est au départ un agenda destiné à répertorier des événements de toutes natures. Le but est de les dater (forcément) , de les qualifier selon de nombreux critères, de les localiser, de les commenter.

Il faut pouvoir présenter ces événements, et surtout permettre de faire des recherches dans cet agenda sur base des critères de qualification.

L'encodage d'une entrée dans l'agenda sera réservé au visiteurs identifiés, et la consultation publique.

Ca c'est la version de base.
Une évolution vers des calendriers privés est envisagée pour:

- Etablir un calendrier privé, d'une communaute, ou groupe d'utilisateurs
- Lier un utilisateur à une entrée de l'agenda pour créer des listes de particpants à un événement

Pour une démo, il faudra patienter un peu que l'on fasse passer le spip modifié depuis l'intranet sur un site public. Et pour le code, je dois en demander au moins demander l'autorisation à son programmeur, même si je ne doute pas de sa réponse favorable.

Le problème, parce qu'il faut bien qu'il y ait un problème, c'est
que ce résultat impose des modifications dans le noyau de Spip.

Normal.

Oui c'est sur.
Mais ce qui nous retient encore, c'est de se retrouver avec un noyau tellement modifié qu'il deviendrait pénible de le réadapter à chaque nouvelle version de spip. Raison pour laquelle je me demandais si ce problème avait déjà fait l'objet d'un débat débouchant sur une methode simple, quasi portable de version de spip en spip.
En fait c'est l'idée d'une modularité de spip qui me vient à l'esprit. Partir d'un noyaux Spip de base, et d'ajouter les modules correspondants a des fonctionnalités en option permettant de composer le produit fini comme on le ferait d'un légo.

a terme les extentions envisagées risquent de compter une petite
dizaine de nouvelles boucles

Tant que ça ??? Pas juste pour un agenda alors ?

Non, pas rien que pour l'agenda.
Et d'ailleurs pas tout tout de suite.
Mais à l'échéance d'un ou deux ans ça pourrait être le cas si l'on arrive à mettre en oeuvre une partie des nombreux projets qui dorment dans les cartons.

Jean-Marc Delforge
VTTnet - www.vtt.org
jm.delforge@vtt.org

Hello,

C'est au départ un agenda destiné à répertorier des événements de
toutes natures. Le but est de les dater (forcément) , de les
qualifier selon de nombreux critères, de les localiser, de les
commenter.

Un agenda, en quelque sorte ... :wink:

L'encodage d'une entrée dans l'agenda sera réservé au visiteurs
identifiés, et la consultation publique.

Comme pour les articles, parfait. Est-ce que, de la même façon, vous
prévoyez qu'un événement soit rattaché à une rubrique et puisse être
enrichi avec des mots clefs ?

Une évolution vers des calendriers privés est envisagée pour:
- Etablir un calendrier privé, d'une communaute, ou groupe
  d'utilisateurs

Cela pourra se gérer avec le même agenda quand la problématique
d'accès réservé aux pages publiques sera résolue convenablement.

- Lier un utilisateur à une entrée de l'agenda pour créer des listes
  de particpants à un événement

Problématique intéressante, en effet.

Pour une démo, il faudra patienter un peu que l'on fasse passer le
spip modifié depuis l'intranet sur un site public.

OK.

Et pour le code, je dois en demander au moins l'autorisation à son
programmeur, même si je ne doute pas de sa réponse favorable.

Normal.

ce qui nous retient encore, c'est de se retrouver avec un noyau
tellement modifié qu'il deviendrait pénible de le réadapter à chaque
nouvelle version de spip.

Oui, bien sûr.

je me demandais si ce problème avait déjà fait l'objet d'un débat
débouchant sur une methode simple, quasi portable de version de spip
en spip.

Pas à ma connaissance.

Comme l'a signalé Antoine Angénieux à propos de l'abstraction de
données, il s'arrange pour coder de telle sorte que les merges depuis
le CVS passent bien. C'est pour l'instant plutôt réussi.

En fait c'est l'idée d'une modularité de spip qui me vient à
l'esprit.. Partir d'un noyaux Spip de base, et d'ajouter les modules
correspondants a des fonctionnalités en option permettant de
composer le produit fini comme on le ferait d'un légo.

C'est impossible dans l'état actuel du moteur de traitement des
squelettes ("Gargantua", si je ne m'abuse).

à l'échéance d'un ou deux ans [...]

Ouh la la, c'est loin deux ans ... :wink:

-Nicolas

Je me permets de vous signaler que le projet PHProject a apparamment
résolu quelques unes des questions qui sont posés ici.

C'est un logiciel de gestion de projets écrit en PHP et disponible en 25 (!)
langues. L'installation est SPIPesque mais les logiciel s'adresse à un public
spécialisé de pros. Une fois qu'on a compris ce que c'est qu'un "projet" ça
s'utilise aussi facilement que SPIP.

Régulièrment des utilisateurs conribuent des modules (gestion d'association,
comptabilité etc.)

La documentation est en Anglais.
http://www.phprojekt.com/

Klaus.