Hello tous,
J'ai terminer la première partie des récapitulatif sur "Comment
ajouter des tables et des boucles dans SPIP" :
http://doc.spip.org/ecrire/?exec=articles&id_article=5860
Je voudrais que des dev de spip / de haut vol passent voir si je ne
raconte pas trops de conneries.
Je passerais faire le tour des fautes demain et mettrais en ligne en suite.
Il reste a documenter la partie installation/création de ces tables.
Pas grand chose donc.
Merci bien.
S'lt
Je viens de parcourir ton article, il est bien.
Peut etre un peu trop dense.
Dans cette optique, je garderais la partie pipeline, et pour la
structure des tables je renverrais plutot sur la partie
http://doc.spip.org/@La-base-de-donnees,4391
En fait ce que je trouve genant c'est que nulle part n'est liée la doc
concernant la base de donnée.
Bon boulot.
Au passage n'hésite pas à publier. Il ne faut pas oublier que le site
est un wik aussi qui permet la collaboration.
S'lt
Je viens de parcourir ton article, il est bien.
Peut etre un peu trop dense.
Oui je m'en suis rendu compte ... Je vais déjà séparer la partie
déclaration des tables/boucles et la partie installation et faire
aussi des part 1, part 2, part3 ...
Dans cette optique, je garderais la partie pipeline, et pour la
structure des tables je renverrais plutot sur la partie
http://doc.spip.org/@La-base-de-donnees,4391
Ben en fait, mon optique était de faire un article complet. Ou on
pourrais avoir tout, ou presque, ce dont on a besoin. Pour ne pas
devoir aller choper des infos sur spip-contrib, les carnets contrib,
doc.spop.org, trac de la zone et dans le code de SPIP. Alors faire des
liens qui renvoient sur d'autres articles, exemples, etc ...y a pas de
souci hein 
En fait ce que je trouve genant c'est que nulle part n'est liée la doc
concernant la base de donnée.
Oui c'est juste. Je vais faire des liens vers cette page et d'autres, pas con
Bon boulot.
Au passage n'hésite pas à publier. Il ne faut pas oublier que le site
est un wik aussi qui permet la collaboration.
Ouép ! bien vu
Seb
S'lt
Ben en fait, mon optique était de faire un article complet. Ou on
pourrais avoir tout, ou presque, ce dont on a besoin.
Le problème des articles comme celui ci c'est soit de trop en dire
pour tout avoir ou ne pas en dire assez 
La difficulté c'est de trouver la limite. Je pense que tu dois essayer
d'etre synthétique autant que possible.
Ma suggestion partait aussi du principe qu'un dev qui cherche de la
doc sur la base de donnée va trouver les pages déjà existantes du coup
ton article devient particulièrement intéressant dans l'aspect
"comment on fait pour un plugin" aspect mal ou pas documenté à l'heure
actuelle.
A mon sens c'est là que réside sa plus value.
De plus aussi ça limite les problèmes de mise à jour de l'information.
Car on limite la redondance donc plus facile à maintenir à terme.
Ce qui est un point à prendre en compte quand on sait le peu de
contributeurs sur ce wiki.
S'lt
doc.spip est très "function driven"
puisque chaque fonction dispose de son espace de doc.
Seulement un secteur du site, un secteur est dédiée à la récupération
des données de svn.
pour des documentations plus globales,
qui portent sur des variables ou autres structures de données,
sur des algorythmes ou des protocoles,
c'est pas encore ça.
C'est améliorable
Il suffit au choix de :
- proposer des améliorations
- coder les amélioration directement, le squelettes étant sur la zone.
- ...
Est-ce qu'un concept global ne pourrait pas être rendu visible
(comme l'espace pour chaque function)
pour facilement attacher une doc au bon endroit,
la référencer ailleurs et y accéder au besoin ?
C'est à dire ? pour ma part je comprends pas ton idée.
Actuellement nous avons un secteur "documentation générale" permettant
de rédiger des articles transversaux au code.
Et pourquoi ne pas mettre une doc plus complète telle que celle-ci sur spip.net, tout simplement ?
-Nicolas
Pour ma part je préfèrerais qu’on évite de rajouter sur spip.net des éléments qui sont relatifs aux plugins, aux hacks, etc…
spip.net s’adresse d’abord à des utilisateurs qui utilisent SPIP ou qui montent des boucles. Rajouter un niveau de complexité risque de noyer pas mal de personnes (et ce n’est pas le même public, ahma).
mes 2 cents,
.Gilles
Pas le même public, certes, mais tout ça est lié au « core » de SPIP, donc ça a à mon avis du sens d'avoir l'info sur le site de référence.
Pas au même endroit, certes, mais sur le même site. D'ailleurs : http://www.spip.net/fr_rubrique205.html
-Nicolas
Les plugins, astuces & co ont plus leur place sur Contrib (les plugins étant plus spécifiquement disponibles via plugins.spip qui reste un site de listage)
Gilles VINCENT a écrit :
Je ne suis pas sûr qu'il soit clair pour tout le monde que plugins.spip.net ne doit être qu'un site de listage ou annuaire, et non un n-ieme lieu de dispersion de la documentation...
Quand je vois que l'on commence à y rédiger de la doc, et a y ouvrir un forum, cela pose des questions sur le positionnement vis a vis de spip-contrib et il me semble que cela contribue in fine a perdre un peu plus l'utilisateur qu'à l'aider...
Pour ma part, je pense que jeter l'existant à la poubelle et recommencer de zéro serait un gachis, et que spip-contrib contient une richesse éditoriale qui est un atout et doit donc être mieux exploité, quitte à avoir une variante dédiée plugins qui soit consacrée à la navigation dans les plugins, et au référencement rapide de plugins.
Cédric
Après tout, pourquoi pas, mais il faudrait que la séparation sur spip.net soit très claire…
Il y a déjà des documents techniques de référence sur doc.spip (cf. les article d’Emmanuel, par exemple), autant tout regrouper la-bas ce qui est lié à l’usage de l’API PHP que nous offre SPIP
.Gilles
Pour ma part je préfèrerais qu’on évite de rajouter sur spip.net des éléments qui sont relatifs aux plugins, aux hacks, etc…
spip.net s’adresse d’abord à des utilisateurs qui utilisent SPIP ou qui montent des boucles. Rajouter un niveau de complexité risque de noyer pas mal de personnes (et ce n’est pas le même public, ahma).Pas le même public, certes, mais tout ça est lié au « core » de SPIP, donc ça a à mon avis du sens d’avoir l’info sur le site de référence.
Après tout, pourquoi pas, mais il faudrait que la séparation sur spip.net soit très claire…
Il me semble qu’elle l’est déjà pas mal :
Mais ça pourrait éventuellement être encore plus explicite, par exemple :
Il y a déjà des documents techniques de référence sur doc.spip (cf. les article d’Emmanuel, par exemple), autant tout regrouper la-bas ce qui est lié à l’usage de l’API PHP que nous offre SPIP
Personnellement, je n’ai jamais compris la logique cet éparpillement, si ce n’est une facilitation des travaux sur chaque site par des équipes différentes.
Et j’ai souvent entendu des remarques de personnes cherchant à découvrir SPIP et ne comprenant pas où se trouvent les infos sur tel ou tel sujet.
Histoire de rationaliser et mieux orienter les visiteurs, l’idéal serait peut-être de migrer sur doc.spip.org toutes les documentations (y compris fonctionnelles), et ne faire de spip.net (migré sur spip.org pour montrer l’esprit libre ?) plus qu’une vitrine présentant le logiciel et un « portail » d’accès aux différents sites de l’univers SPIP.
On aurait ainsi une vraie logique avec des sous domaines de spip.org bien identifiés. spip-contrib.net pourrait de même devenir contribs.spip.org, et de même pour d’autres.
Cela permettrait de conserver les plateformes techniques actuelles, tout en rationalisant l’ensemble.
Et faire une mutualisation du noyau?.. grâce aux sous-domaines?
Et faire une mutualisation du noyau?.. grâce aux sous-domaines?
Ce serait un bon cas concret de mise en oeuvre de la mutualisation, mais cela impose une plateforme technique unique, et donc des contraintes sur les personnes qui peuvent toucher au système. La répartition actuelle sur plusieurs plateforme a au moins le mérite de multiplier les compétences et de répartir de fait les charges dues au trafic. Quand une plateforme tombe, les autres restent dispo.
cam.lafit@azerttyu.net a écrit :
Ben en fait, mon optique était de faire un article complet. Ou on
pourrais avoir tout, ou presque, ce dont on a besoin.Le problème des articles comme celui ci c'est soit de trop en dire
pour tout avoir ou ne pas en dire assez
La difficulté c'est de trouver la limite. Je pense que tu dois essayer
d'etre synthétique autant que possible.
doc.spip est très "function driven"
puisque chaque fonction dispose de son espace de doc.
pour des documentations plus globales,
qui portent sur des variables ou autres structures de données,
sur des algorythmes ou des protocoles,
c'est pas encore ça.
Est-ce qu'un concept global ne pourrait pas être rendu visible
(comme l'espace pour chaque function)
pour facilement attacher une doc au bon endroit,
la référencer ailleurs et y accéder au besoin ?
De plus aussi ça limite les problèmes de mise à jour de l'information.
Car on limite la redondance donc plus facile à maintenir à terme.
Ce qui est un point à prendre en compte quand on sait le peu de
contributeurs sur ce wiki.
ben oui...
moi j'ai manqué de cette structure porteuse, préallable
à laquelle l'existant doc.spip nous habitue avec les function
et nous invite pour le reste.
JL
On sort un peu du topic de ce fil, mais je suis totalement d'accord.
Pour les auteurs, ça multiplie le travail de maintenance et pour les visiteurs, ça complexifie les recherche.
amha, plugins.spip.net n'affirme pas encore assez son identité, probablement parce que ses auteurs ne la circonscrivent pas encore...
Pat
cedric.morin@yterium.com a écrit :
Le 14 oct. 08 à 17:25, Samy RABIH a écrit :
Les plugins, astuces & co ont plus leur place sur Contrib (les plugins étant plus spécifiquement disponibles via plugins.spip qui reste un site de listage)
Je ne suis pas sûr qu'il soit clair pour tout le monde que plugins.spip.net ne doit être qu'un site de listage ou annuaire, et non un n-ieme lieu de dispersion de la documentation...
Quand je vois que l'on commence à y rédiger de la doc, et a y ouvrir un forum, cela pose des questions sur le positionnement vis a vis de spip-contrib et il me semble que cela contribue in fine a perdre un peu plus l'utilisateur qu'à l'aider...Pour ma part, je pense que jeter l'existant à la poubelle et recommencer de zéro serait un gachis, et que spip-contrib contient une richesse éditoriale qui est un atout et doit donc être mieux exploité, quitte à avoir une variante dédiée plugins qui soit consacrée à la navigation dans les plugins, et au référencement rapide de plugins.
Cédric
Nicolas Hoizey a écrit :
Et j'ai souvent entendu des remarques de personnes cherchant à découvrir SPIP et ne comprenant pas où se trouvent les infos sur tel ou tel sujet.
tout a fait d'accord....................d'ailleurs j'ai perdu des futurs spipiens qui partent sur joomla et guppy
Histoire de rationaliser et mieux orienter les visiteurs, l'idéal serait peut-être de migrer sur doc.spip.org toutes les documentations (y compris fonctionnelles), et ne faire de spip.net (migré sur spip.org pour montrer l'esprit libre ?) plus qu'une vitrine présentant le logiciel et un « portail » d'accès aux différents sites de l'univers SPIP.
On aurait ainsi une vraie logique avec des sous domaines de spip.org bien identifiés. spip-contrib.net pourrait de même devenir contribs.spip.org, et de même pour d'autres.
Cela permettrait de conserver les plateformes techniques actuelles, tout en rationalisant l'ensemble.
-Nicolas
--
Nicolas HOIZEY
http://www.gasteroprod.com/
très bonne idées parce que ça commence a être un poil complexe
@micalement stéphane