[SPIP Zone] Appel à l'ordre (site Programmer)

Archives Zone
1

Bonjour à tous,

Je sollicite aujourd'hui votre bienveillance et votre motivation pour le site programmer.spip.org. J'aurais besoin (de nouveau) de vos réflexions sur l'organisation des contenus (chapitres) de ce site.

Voilà la situation telle que je la perçois :
- le Chapitre 2 (Ecriture des squelettes) me convient pour l'instant
- tous les autres pourraient être réorganisés selon une autre structure à définir car le reste est un peu mal structuré il me semble.

Je prends par ailleurs une remarque de Rastapopoulos très au sérieux : avoir un rubricage par fonction (Comment faire ceci, cela) de préférence à une structure comme «le répertoire Balise», «le répertoire Auth». Par conséquent, déjà, j'aimerais reprendre ce chapitre (à peine commencé) «les différents répertoires» pour ne faire qu'un court article par répertoire, le reste serait décrit dans des chapitres plus adaptés comme «Réaliser une page privée» (qui parlerait donc des exec/ entre autre)…

J'aimerais donc de nouveau votre avis, maintenant que le site a un peu plus de bouteille : « *Quelle serait selon vous la table des matières idéale pour un livre parlant du développement avec SPIP ?* »

Pour info, actuellement le plan c'est ça :
http://programmer.spip.org/spip.php?page=plan&lang=fr

Merci mille fois d'essayer de nous aider dans cette tâche difficile de structuration.

--
MM.

2

Le 15 sept. 2009 à 11:38, Matthieu Marcillaud a écrit :

Voilà la situation telle que je la perçois :
- le Chapitre 2 (Ecriture des squelettes) me convient pour l'instant
- tous les autres pourraient être réorganisés selon une autre structure à définir car le reste est un peu mal structuré il me semble.
Je prends par ailleurs une remarque de Rastapopoulos très au sérieux : avoir un rubricage par fonction (Comment faire ceci, cela) de préférence à une structure comme «le répertoire Balise», «le répertoire Auth».

C'est plus une approche de type tutoriel que documentation exhaustive du coup. Les deux me semblent nécessaires, mais c'est vrai que la seconde est censée être mise en place sur SPIP.net

Par conséquent, déjà, j'aimerais reprendre ce chapitre (à peine commencé) «les différents répertoires» pour ne faire qu'un court article par répertoire, le reste serait décrit dans des chapitres plus adaptés comme «Réaliser une page privée» (qui parlerait donc des exec/ entre autre)…

Bonne idée.

J'aimerais donc de nouveau votre avis, maintenant que le site a un peu plus de bouteille : « *Quelle serait selon vous la table des matières idéale pour un livre parlant du développement avec SPIP ?* »

Je pense qu'il faudrait essayer de suivre la progression la plus courante dans l'usage qui est fait de SPIP.

Pour ma part, reste à vérifier si c'est courant, je dirais à chaud :

- installer SPIP
- configurer SPIP pour l'adapter à ses besoins
   - configuration fonctionnelle dans ecrire/
   - configuration technique avec des constantes/variables dans mes_options.php
- créer mes propres squelettes
   - ce que contient squelettes-dist
   - la modularité avec les notions de noisettes, #INCLURE, <INCLURE...>, etc.
   - ce que je peux ajouter/surcharger
   - Ajax
   - les formulaires
   - la gestion fine du cache
- ajouter des fonctionnalités
   - ajout de filtres
   - utilisation de plugins existants
   - création de plugins

-Nicolas

--
Nicolas HOIZEY
Blog : http://www.gasteroprod.com/
Photos : http://flic.kr/nicolas-hoizey/

3

* Nicolas Hoizey tapuscrivait, le 15/09/2009 21:39:

- ajouter des fonctionnalités
  - ajout de filtres
  - utilisation de plugins existants
  - création de plugins

Et hier, j'ai cherché sans trouver dans le site : "Création de balises (non dynamique)"

--
RealET

4

Bonjour,

Il y a quelque temps, j’avais cherché la liste des champs configurés dans l’espace privé de spip.

Un exemple: je voulais afficher une noisette uniquement si les statistiques étaient activées
ou bien
je veux afficher un lien vers la page d’inscription uniquement si les inscriptions sont configurées.
ou encore
je voudrais savoir quelles langues sont utilisées ou permises…

En fouinant dans les tables, j’ai trouvé la table spip_meta qui renseigne toutes les variables de configuration.

Je ne sais pas si c’est la bonne méthode mais j’ai donc utilisé du code php comme ceci:

<?php if (($GLOBALS['meta']['activer_statistiques] == 'oui') {?>

…

<?php } ?>

ou encore

<?php if (($GLOBALS['meta']['accepter_inscriptions'] == 'oui') or ($GLOBALS['meta']['accepter_visiteurs'] == 'oui')) {?>

…

<?php } ?>

Le problème est que n’importe quel plugin peut écrire dans cette table.
Ce serait bien de pouvoir distinguer les champs natifs de spip et leurs valeurs de ceux ajoutés par les plugins.
Il faudrait aussi détailler la balise #CONFIG.

Peut-être c’est ce qu’on entendrait aussi par « la configuration de l’espace privé » ?

–
damazone

5

Le 15/09/2009 21:39, Nicolas Hoizey a écrit :

- installer SPIP
- configurer SPIP pour l'adapter à ses besoins
- configuration fonctionnelle dans ecrire/
- configuration technique avec des constantes/variables dans
mes_options.php
- créer mes propres squelettes
- ce que contient squelettes-dist
- la modularité avec les notions de noisettes, #INCLURE, <INCLURE...>, etc.
- ce que je peux ajouter/surcharger
- Ajax
- les formulaires
- la gestion fine du cache
- ajouter des fonctionnalités
- ajout de filtres
- utilisation de plugins existants
- création de plugins

Attention, car programmer.spip.org c'est pour... les programmeurs.

Donc il ne faut pas trop de chapitres qui soient juste "utiliser telle chose". C'est surtout un site pour apprendre à *créer*. Créer des squelettes, des filtres, des balises, modifier un comportement par défaut (pipelines et autorisations), ajouter une fonctionnalité avec un plugin, etc.

--
RastaPopoulos

6

RastaPopoulos a écrit :

Attention, car programmer.spip.org c'est pour... les programmeurs.

Donc il ne faut pas trop de chapitres qui soient juste "utiliser telle chose". C'est surtout un site pour apprendre à *créer*. Créer des squelettes, des filtres, des balises, modifier un comportement par défaut (pipelines et autorisations), ajouter une fonctionnalité avec un plugin, etc.

Oui c'est vrai, pas question de reproduire une doc pour ces plugins.
Mais d'une part, l'utilisation de certains plugins fait appel
à de la programmation, ce pour quoi la doc est fort peu développée ailleurs.

En effet, un certains types de plugins ne sont pas utilisables clé en main :
ce sont des briques pour programmer.
Et donc, tandis que la doc des plugins décrit leur utilisation
souvent "par le petit bout de la lorgnette" (hors contexte et sans intro)
programmer.spip peut avoir une vision d'altitude sur l'utilisation des plugins
et peut présenter comment les choisir et les utiliser
en les combinant, par exemple, pour obtenir un effet voulu.

JLuc

7

Peut-être dans un deuxième temps, et encore je ne sais pas si c'est vraiment le rôle de ce site là.
À la limite CFG entre peut-être dans le cadre c'est il sert à ajouter une fonctionnalité de configuration (quelle qu'elle soit), mais il a déjà une documentation plutôt fourni sur contrib.

La première étape ça reste quand même d'avoir une documentation sur tout ce qui permet d'étendre la base de SPIP, à partir du noyau. Si déjà on arrive à un truc bien rangé avec tout ça (il a déjà beaucoup à dire), ça sera pas mal.

--
RastaPopoulos

8

Le 16 sept. 2009 à 10:40, RastaPopoulos a écrit :

Le 15/09/2009 21:39, Nicolas Hoizey a écrit :

- installer SPIP
- configurer SPIP pour l'adapter à ses besoins
- configuration fonctionnelle dans ecrire/
- configuration technique avec des constantes/variables dans
mes_options.php
- créer mes propres squelettes
- ce que contient squelettes-dist
- la modularité avec les notions de noisettes, #INCLURE, <INCLURE...>, etc.
- ce que je peux ajouter/surcharger
- Ajax
- les formulaires
- la gestion fine du cache
- ajouter des fonctionnalités
- ajout de filtres
- utilisation de plugins existants
- création de plugins

Attention, car programmer.spip.org c'est pour... les programmeurs.

OK, donc on peut retirer les 3 premiers chapitres qui ne nécessitent normalement aucune ligne de code.

Mais "configuration... dans mes_options.php", c'est du code, sans être à proprement parler du développement, donc on garde ou pas ?

La frontière n'est pas toujours évidente entre utilisation et développement, donc essayer plutôt de rationaliser la doc globale sur un seul site ne serait-il pas plus pertinent ?

Donc il ne faut pas trop de chapitres qui soient juste "utiliser telle chose". C'est surtout un site pour apprendre à *créer*. Créer des squelettes, des filtres, des balises, modifier un comportement par défaut (pipelines et autorisations), ajouter une fonctionnalité avec un plugin, etc.

--
RastaPopoulos

_______________________________________________
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

-Nicolas

--
Nicolas HOIZEY
Blog : http://www.gasteroprod.com/
Photos : http://flic.kr/nicolas-hoizey/

9

RastaPopoulos a écrit :

À la limite CFG

Je pensais surtout aux plugins qui définissent une API
ou leurs propres pipeline qu'il faut utiliser avec php :
il me semble que AUTORISER, NOTIFICATION, FACTEUR, ...
en font partie,

ou à des problématiques concrètes courantes
pour lesquelles il faut passer par plusieurs plugins
- parcequ'il faut les combiner et c'est de la programmation,
et en plus parceque parfois il faut choisir parmi différentes
voies/algorythmes et que ça c'est déjà de la programmation
pour laquelle il faut de la méta-doc )

Là je pense en plus à des trucs comme
autorisations/acces_restreint/#SESSION
mais il pourrait aussi y avoir facteur/spip_liste/clevermail/...,
CFG/CVT/SAISIE, les trucs sur les auteurs et inscriptions, etc...

Je ne connais pas bien tous ces plugins donc je peux me tromper
mais il me semble qu'ils définissent une API
et qu'ils posent des questions d'arbitrages/choix
(donc de "programmation").

La première étape ça reste quand même d'avoir une documentation sur tout ce qui permet d'étendre la base de SPIP, à partir du noyau.

Il y a en effet plein de trucs à dire rien qu'à partir du noyau.

ça peut structurer la doc en 2 parties :
1ère partie :
- API du noyau : Ah ! Enfin le come'out d'une API SPIP !
2ème partie :
- avec autre chose que du noyau

Bises à mat
JL
JLuc

10

Le 15/09/2009 21:39, Nicolas Hoizey a écrit :

Pour ma part, reste à vérifier si c'est courant, je dirais à chaud :

- installer SPIP
- configurer SPIP pour l'adapter à ses besoins
- configuration fonctionnelle dans ecrire/
- configuration technique avec des constantes/variables dans
mes_options.php
- créer mes propres squelettes
- ce que contient squelettes-dist
- la modularité avec les notions de noisettes, #INCLURE, <INCLURE...>, etc.
- ce que je peux ajouter/surcharger
- Ajax
- les formulaires
- la gestion fine du cache
- ajouter des fonctionnalités
- ajout de filtres
- utilisation de plugins existants
- création de plugins

Bon, maintenant que la poussière est tombée, je donne un point de vue sur les différentes remarques faites ici où là…

Oui, programmer a pour but de programmer avec SPIP, mais cela représente il me semble 2 choses : concevoir les squelettes d'un site, et programmer des modules pour SPIP ou le site.

Dans le premier cas, ce qui est intéressant, c'est à la fois de comprendre comment on *écrit* un squelette (boucle, filtres, critères, balises…), quels sont ceux qui sont fournis par SPIP, et comment les utiliser.

Le deuxième cas s'intéresse plutôt à comment on *crée*, modifie ou étend des objets et éléments de SPIP.

Pour l'instant, je préfère clairement tenter de développer le 2è cas car c'est il me semble que c'est la partie de la documentation la moins structurée dans la galaxie SPIP. Le premier cas étant assez bien rempli par SPIP.net dans l'ensemble. Paradoxalement, ce 2è cas, c'est aussi le contenu le moins écrit de Programmer, mais le temps améliorera les choses quand je serais de nouveau satisfait de l'organisation des chapitres…

----

La proposition de Nicolas sur l'installation est intéressante… Je n'étais pas partie du tout pour décrire comment installer SPIP (par contre je voulais parler de la mutualisation)… Mais à bien réfléchir, ça serait aussi intéressant de présenter la récupération et installation de SPIP, au moins via les commandes SVN (puisqu'on s'adresse a des gens susceptibles de pouvoir participer à la création et l'amélioration de SPIP) : cela permet de donner des éléments sur : comment fournir un patch, un diff, corriger des coquilles sur les plugins, etc.

----

Concernant la documentation technique de plugins, c'est le plus problématique… Mais c'est vrai que regrouper dans un livre des éléments de cette nature peut être intéressant, du moins structurant. C'est surtout un gros travail qui duplique aussi Contrib… Mais c'est sur qu'il y a des plugins tellements imbriqués dans SPIP que ça va être dur à un moment de passer outre (Crayons est l'exemple parfait). SPIP 2.1 en aura en plus des vrais de vrai d'office dans extensions/ qu'il faudra bien documenter aussi…

----

Enfin, je rebondis sur une remarque d'Amaury (je crois), sur IRC, qui très justement indique que les pages http://programmer.spip.org/Modulaire-et-Ajax et http://programmer.spip.org/Evolutif-et-securise n'ont pas à être dans l'introduction… je suis d'avis effectivement de reprendre ailleurs ces deux pages.

----

Sinon, je suis toujours à la recherche du plan idéal hein !

Et merci à ceux qui se sont exprimés.

--
MM.

11

Le 21 sept. 09 à 12:05, Matthieu Marcillaud a écrit :

Sinon, je suis toujours à la recherche du plan idéal hein !

Bonjour Mathieu,

Voici mon plan idéal :

Il pourrait y avoir une partie "inventaire"
Qui détaillerait un peu comme les éléments : API, mécanismes propre à spip , mécanismes très utilisés par spip mais pas spécifiques, prospective

une seconde partie pourrait regrouper des exemples d'utilisation en commentant ce qu'il y a dans les plugins et spip.

La navigation transversale pourrait être un index.

Bon je dis cela mais la tâche me parait gigantesque...

@+

pierre