J’utilise spip depuis quelques années sans arriver à pouvoir réellement participer à son développement faute de compréhension, car le code de SPIP est complexe (en nombre de ligne déjà existantes, utilise ces propres fonctions, documentation parfois absentes… ) j’ai donc commencé à créer un script qui épluché le contenu des plugins de spip et en sortir des informations sur celui-ci :
nombre de fichiers pour chaque types (php, image, css, et surtout fonctions php) et les afficher sur une seule page web afin de permettre la lecture sans devoir se balader des tous les répertoires et de les ouvrir un par un avec un éditeur. En gros c’est plus rapide et on peut surtout mettre des liens pour télécharger , vers le trac et la doc et autres.
Mon script généré donc de simple pages html, puis jai voulu ajouté un cache, permettre une recherche dans les plugins, plutot tous codé, j’ai pensé à utiliser SPIP ( bizarre ) et rentré ces pages html sous forme de rubriques/articles grâce à ces scripts bash, afin de profiter du cache , de la recherche, des raccourci spip [lien->] et du couteau suisse et de son sommaire automatique et sans doute d’autre, c’est maintenant chose faites et en ligne.
Mon script généré donc de simple pages html, puis jai voulu ajouté un
cache, permettre une recherche dans les plugins, plutot tous codé, j'ai
pensé à utiliser SPIP ( bizarre ) et rentré ces pages html sous forme de
rubriques/articles grâce à ces scripts bash, afin de profiter du cache ,
de la recherche, [...]
En fait tu as un peu réinventé la route, même si ce n'est pas exactement pour le même besoin.
Il se trouve que le site doc.spip.org est *justement* construit comme ça : un script parcours le code, et génère alors des rubriques/articles en extrayant la documentation interne au code et en produisant des liens automatiques. L'avantage étant de pouvoir compléter la documentation avec un champ wiki en plus.
Alors oui : le script est cassé depuis des mois et des mois. Et il pourrait éventuellement sortir des informations supplémentaires. Mais sur le principe, c'est la même chose et ça existe déjà.
Un chantier des Grottes sera peut-être (!) de remettre tout ça au propre. Notamment pour :
1) faire en sorte que ça remarche à nouveau
2) fournir plus d'informations
3) que la documentation marche dans les *deux* sens : si on ajoute de la doc sur le site, le script pourrait la reporter dans le code ensuite
4) prendre en compte certains plugins de toute façon (ceux du core) puisque SPIP est découpé en morceaux.
doc.spip.org ne restera que pour SPIP à priori (et ses extensions). Mais si le script marche bien, d'autres pourront éventuellement l'utiliser pour parcourir les plugins, si ça les chante.
fonctions, documentation parfois absentes... ) j'ai donc commencé à créer un
script qui épluché le contenu des plugins de spip et en sortir des
informations sur celui-ci :
Super. Peux-tu mettre des rel=nofollow sur les liens vers le trac ?
Un chantier des Grottes sera peut-être (!) de remettre tout ça au propre. Notamment pour :
faire en sorte que ça remarche à nouveau
fournir plus d’informations
que la documentation marche dans les deux sens : si on ajoute de la doc sur le site, le script pourrait la reporter dans le code ensuite
prendre en compte certains plugins de toute façon (ceux du core) puisque SPIP est découpé en morceaux.
Dommage pour les grottes, je voulais venir (pour en autres) pour parler de ça.
Sinon pour le coup de réinventer la rou(t)e, oui et non, car doc.spip.org est très bien mais pour quelqu’un qui sait ce qu’il cherche un minimum.
Je pense( en tous cas c’est ce qui c’est passé pour moi ) qu’on commence par faire c’est squelettes (la y a de la doc « un peu » partout), puis on souhaite modifier un plugin et la mon outil est pas mal pour voir à quoi on a a faire rapidement et aussi récupérer rapidement la dernière version.
Après comme je l’indique dans les améliorations c’est de le lié ( je mettrai rel=nofollow ) avec doc.spip.org (concernant les fonctions) et la je participerai (avec le script automatiquement ou en entrant les infos à la main qui manque souvent de description), car sinon je referai tous le travail de doc.spip.org pour le coup.
Comme dit plus tot, tu réinventes une bonne partie de doc.spip.org. Tu
t'appuies sur les memes principes.
J'apprécie bien l'approche.
ça serait un super projet de pouvoir redonner du grain à notre hibou.
Ce que tu as fait va en complément de l'existant, on peut essayer de
voir pour regrouper le tout pour donner plus de vigueur au tout.
Sinon pour le coup de réinventer la rou(t)e, oui et non
Peu importe ce qui est généré au final, pour moi c'est annexe.
J'ai bien précisé que ce n'était pas le même but final. Mais le principe de la moulinette est exactement le même : un script qui parcourt le code et qui génère des rubriques et articles SPIP en conséquence.
La seule différence c'est que les deux scripts ont un choix différents de quelles informations sont sorties. Mais ça, ça peut toujours se modifier suivant l'amélioration du script.
Ceci dit, je pense que le script actuel de doc.spip.org doit être revu depuis zéro, tout comme Cédric avait refait complètement le script de génération des paquets. Donc ça sera bien d'avoir ton code le moment venu : on pourra reprendre les bonnes idées dans chacun des scripts.
Sinon pour le coup de réinventer la rou(t)e, oui et non, car doc.spip.org est très bien mais pour quelqu'un qui sait ce qu'il cherche un minimum.
Je pense( en tous cas c'est ce qui c'est passé pour moi ) qu'on commence par faire c'est squelettes (la y a de la doc "un peu" partout), puis on souhaite modifier un plugin et la mon outil est pas mal pour voir à quoi on a a faire rapidement et aussi récupérer rapidement la dernière version.
Je suis assez d'accord avec ton « oui et non » : je n'ai jamais compris à quoi doc.spip.org peut servir... alors que j'allais m'exclamer « énorme » sur ce que tu viens de proposer. C'est la liste des plugins qui me plaît : mieux que le séduisant (mais incomplet) plugins.spip.net ou le documenté (mais pas toujours à jour) spip-contrib.net, que l'on espérait fusionner, ce que tu propose va puisser l'info à la source. Amen.
Comme dis plus haut, à moins de trouver un covoiturage pour une journée montpellier → Les Grottes d’ici là je ne serai pas présent.
Pour le code, j’ai essayé de bien rangé tous ça mais c’est très usine à gaz, en fait il faut que je fasse aussi un script/site pour expliquer ce code là c’est une boucle sans fin…
Le mieux, je vais essayer de nettoyer le code et d’expliquer son fonctionnement sur mon blog comme ça vous pourrez prendre ce qui vous intéresse, il faut aussi que je regarde comment était fait le script pour doc.spip.org (ça doit être quelques par sur le trac?), moi c’est vraiment du bash (pas une ligne de perl, peut-être que ça serait plus propre mais j’arrive à extraire tous ce que je veux pour l’instant grâce à bash et c’est vraiment un langage que j’apprécie ).
Sinon pour le coup de réinventer la rou(t)e, oui et non
Peu importe ce qui est généré au final, pour moi c’est annexe.
J’ai bien précisé que ce n’était pas le même but final. Mais le principe de la moulinette est exactement le même : un script qui parcourt le code et qui génère des rubriques et articles SPIP en conséquence.
La seule différence c’est que les deux scripts ont un choix différents de quelles informations sont sorties. Mais ça, ça peut toujours se modifier suivant l’amélioration du script.
Ceci dit, je pense que le script actuel de doc.spip.org doit être revu depuis zéro, tout comme Cédric avait refait complètement le script de génération des paquets. Donc ça sera bien d’avoir ton code le moment venu : on pourra reprendre les bonnes idées dans chacun des scripts.
Comme dis plus haut, à moins de trouver un covoiturage pour une journée
montpellier -> Les Grottes d'ici là je ne serai pas présent.
Dommage, mais si tu passe à l'occasion par Lyon.
il faut aussi que je regarde comment était fait le script pour
doc.spip.org (ça doit être quelques par sur le trac?), moi c'est vraiment du
bash (pas une ligne de perl, peut-être que ça serait plus propre mais
j'arrive à extraire tous ce que je veux pour l'instant grâce à bash et c'est
vraiment un langage que j'apprécie ).
Oui tu es sur le trac dans _galaxie_ et outils. C'est principalement
Bash, php et squelettes SPIP
Mais comme on le dit avec Rasta, il faut reprendre les bases du code
actuel car ton intrinseque à la plateforme d'éxecution d'origine.
Maintenant que la zone a été migré et semble enfin stabiliser. Je
prévois de migrer doc.spip.org et ainsi de pouvoir le reprendre sur
des bases plus saines.
Sinon pour le coup de réinventer la rou(t)e, oui et non, car doc.spip.org est très bien mais pour quelqu'un qui sait ce qu'il cherche un minimum.
Je pense( en tous cas c'est ce qui c'est passé pour moi ) qu'on commence par faire c'est squelettes (la y a de la doc "un peu" partout), puis on souhaite modifier un plugin et la mon outil est pas mal pour voir à quoi on a a faire rapidement et aussi récupérer rapidement la dernière version.
Je suis assez d'accord avec ton « oui et non » : je n'ai jamais compris à quoi doc.spip.org peut servir... alors que j'allais m'exclamer « énorme » sur ce que tu viens de proposer. C'est la liste des plugins qui me plaît : mieux que le séduisant (mais incomplet) plugins.spip.net ou le documenté (mais pas toujours à jour) spip-contrib.net, que l'on espérait fusionner, ce que tu propose va puisser l'info à la source. Amen.
Tu n'as jamais compris car cela ne correspond pas du tout à tes
besoins. doc.spip.org est principalement là pour informer de la
structure du code existant avec les définitions de chaque fonctions,
leur écriture, leur exemple de code et leur place dans l'architecture
actuelle.
Le 07 mai 2010 à 11:49, cam.lafit@azerttyu.net a écrit :
S'lt
Sinon pour le coup de réinventer la rou(t)e, oui et non, car doc.spip.org est très bien mais pour quelqu'un qui sait ce qu'il cherche un minimum.
Je pense( en tous cas c'est ce qui c'est passé pour moi ) qu'on commence par faire c'est squelettes (la y a de la doc "un peu" partout), puis on souhaite modifier un plugin et la mon outil est pas mal pour voir à quoi on a a faire rapidement et aussi récupérer rapidement la dernière version.
Je suis assez d'accord avec ton « oui et non » : je n'ai jamais compris à quoi doc.spip.org peut servir... alors que j'allais m'exclamer « énorme » sur ce que tu viens de proposer. C'est la liste des plugins qui me plaît : mieux que le séduisant (mais incomplet) plugins.spip.net ou le documenté (mais pas toujours à jour) spip-contrib.net, que l'on espérait fusionner, ce que tu propose va puisser l'info à la source. Amen.
Tu n'as jamais compris car cela ne correspond pas du tout à tes
besoins.
Oui, bien sûr
C'est aussi ce qui me fait trouver la proposition de Nicolas hautement intéressante.
Et je ne suis pas la seule à rechercher parmi les plugins...
Peu m'importe que ça ré-invente la roue si la nouvelle est plus utilisable que l'ancienne
c’est une boucle sans fin…