Bonjour a tous, question tres bete, mais je viens de relever cette page sur spip-contrib.net, je comprend pour spip (bien que ce soit la 1.7) mais Agora la, je pige pas 
ref = http://www.spip-contrib.net/Barre-typographique-enrichie
@plus, karim
–
dsl pour les accents, clavier querty 
* karim belkacem tapotait, le 19/08/2006 18:18:
Bonjour a tous, question tres bete, mais je viens de relever cette page sur spip-contrib.net <http://spip-contrib.net>, je comprend pour spip (bien que ce soit la 1.7) mais Agora la, je pige pas
Parce que Connexion · GitLab
--
Jacques — SPIP - Pyrat.net – Création de sites Internet
salut, c’est bete, ca vaut pas un vrai article, sur par exemple spip-contrib.net, pour mieux comprendre la finalite, m’enfin pour ce que j’en dit et pense.
@plus, karim
2006/8/19, Jacques PYRAT <spip.newsgroup@pyrat.net>:
- karim belkacem tapotait, le 19/08/2006 18:18:
Bonjour a tous, question tres bete, mais je viens de relever cette page
sur spip-contrib.net < http://spip-contrib.net>, je comprend pour spip
(bien que ce soit la 1.7) mais Agora la, je pige pasref = http://www.spip-contrib.net/Barre-typographique-enrichie
Parce que http://zone.spip.org/trac/spip-zone/changeset/3506–
Jacques — http://www.pyrat.net/-SPIP-.html
liste spip
spip@rezo.net - désabonnement : spip-off@rezo.net
Infos et archives : http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP : http://www.spip.net/
irc://irc.freenode.net/spip
FAQ : http://www.spip-contrib.net/spikini/FaQ
–
dsl pour les accents, clavier querty 
* karim belkacem tapotait, le 19/08/2006 18:39:
salut, c'est bete, ca vaut pas un vrai article, sur par exemple spip-contrib.net <http://spip-contrib.net>, pour mieux comprendre la finalite, m'enfin pour ce que j'en dit et pense.
Un vrai article, je sais pas.
Quelques explications, sans doute.
Il est notoire :
- qu'AGORA est *utile* à certaines administrations française
- qu'AGORA a des fonctionnalités propres à les satisfaire et dont la communauté SPIP n'a que faire
- qu'AGORA est basé sur le moteur 1.7 de SPIP et donc largement à la traine quant aux possibilités des squelettes...
Donc, il est *raisonnable* de pouvoir envisager qu'un jour, plugins après plugins, on puisse disposer d'un équivalent fonctionnel d'AGORA bénéficiant du moteur de SPIP.
Donc, astalavista AGORA !
Bonjour les plugins AGORA.
--
Jacques — SPIP - Pyrat.net – Création de sites Internet
salut
Il est notoire :
- qu’AGORA est utile à certaines administrations française
ca reste a prouver, disont plutot qu’elles sont « coincees », m’enfin si tu le dit je te crois.
- qu’AGORA a des fonctionnalités propres à les satisfaire et dont la
communauté SPIP n’a que faire
c’est exactement le sujet de mon interrogation, pourquoi mentionner spip agora sur spip-contib, je repose la question ?
Donc, il est raisonnable de pouvoir envisager qu’un jour, plugins
après plugins, on puisse disposer d’un équivalent fonctionnel d’AGORA
bénéficiant du moteur de SPIP.
la encore ca reste a prouver, spip depasse largement agora pour les besoins d’un site d’une administration, les seules vraies raisons que j’y vois, mais ca n’engage que moi sont que agora a ete mal gerer et qu’il faut justifier sa naissance et surtout les depenses astronomiques que sont dev a generees. Les plug-ins n’y pourront rien, j’en ai peur, mais je ne suis pas dans les secrets dieux.
Donc, astalavista AGORA !
Bonjour les plugins AGORA.
c’est ton avis vieux debat, j’ai l’impression de revivre 2003-2004
–
dsl pour les accents, clavier querty
Mon dieu, un tel message alors que depuis plusieurs jours, c'est la Saint Troll ... Mais tu es inconscient Jacques !
:o)
Jacques PYRAT a écrit :
Il est notoire :
- qu'AGORA est *utile* à certaines administrations française
<troll>
Non, non, ce qui est notoire, c'est qu'il est *utilisé*.
*utile*, ca reste à prouver : j'ai posé la question, tu l'as posée aussi...
Sauf si tu as des infos qui te sont parvenues en direct, pour l'instant, on ne connait pas grand monde qui utilise des fonctionnalités qu'on ne trouve pas dans Spip.
C'est meme assez amusant de voir les habitués de la bete fabriquer des sites avec des arborescences de rubriques monstrueuses contenant chacune un article.
Quand au workflow parametrable, tu sais comme moi que c'est de la fumisterie puisqu'il faut coder et que ca coute beaucoup moins cher de maintenir une modif dans Spip.
Et je ne parle meme pas du multibase ... du vent !
Alors c'est quoi les fonctionnalités si indispensables, qui necessitent 2 fois plus de memoire et l'installation de la version beta patchée de PEAR, et qu'il n'y a que dans Agora ?
La gestion hierarchique des mots clés ?
la barre typo enrichie ?
ou le truc de versioning à 2 balles ?
A moins que ca ne soit la super newsletter buguée de CA ...
Non, vraiment Jacques, je ne pense pas qu'*utile* soit le mot qui convienne !
Rien ne justifie ce projet aujourd'hui, et rien ne justifiait un fork aussi mal fait hier.
C'est un projet qui a été utilisé ...
Et continue malheureusement à l'etre, meme si c'est moins bien, meme si ca coute plus cher, juste parce que sinon, ca serait reconnaitre une erreur.
</troll>
Non, plus serieusement, le fait que ces fonctionnalités aient été couvertes par Agora me parait anecdotique, je ne vois pas l'utilité de mettre ces plugins à part.
Je suppose que tu as comme moi un spip de test avec une bonne quinzaine de plugins activés ... tout cela n'a vraiment plus grand chose à voir avec un spip 1.7, aussi modifié soit il.
Lancer une idée de distribution avec un bundle de plugin et eventuellement un ou plusieurs squelettes, ca, ca pourrait etre interessant.
Mais on en revient à la question fondamentale qui ne s'est jamais ou mal posée sur Agora : quel est le besoin fonctionnel ?
Je ne pense pas que le fait qu'une fonctionnalité ait été un jour dans Agora nous renseigne beaucoup sur son utilité réelle.
La seule chose que pourrait nous apporter Agora, ca serait de lever les problemes d'ergonomie rencontrés pour eviter de refaire les memes erreurs.
Mais je pense qu'Agora n'apportera meme pas ca à Spip...
@++
Le 19 août 06, à 20:48, Stephane LAURENT a écrit :
Non, plus serieusement, le fait que ces fonctionnalités aient été
couvertes par Agora me parait anecdotique, je ne vois pas l'utilité de
mettre ces plugins à part.
plus sérieusement, un kit de conversion (si j'ose dire:) à spip 2.x pour les agoraistes. Sans pertes de données, fonctionnalités... (c'est ramener un peu le loup dans la bergerie, mais bon ce doit être pour la beauté du geste)
claude
dlatr a écrit :
Le 19 août 06, à 20:48, Stephane LAURENT a écrit :
Non, plus serieusement, le fait que ces fonctionnalités aient été
couvertes par Agora me parait anecdotique, je ne vois pas l'utilité de
mettre ces plugins à part.plus sérieusement, un kit de conversion (si j'ose dire:) à spip 2.x pour les agoraistes. Sans pertes de données, fonctionnalités... (c'est ramener un peu le loup dans la bergerie, mais bon ce doit être pour la beauté du geste)
Oui, la migration des données, c'est important et ca, et pas forcement specifique à Agora (passage d'un plugin à un autre par exemple ou migration depuis une contrib vers un plugin).
Mais soit ce sont des plugins qui se mettent comme contrainte d'etre compatibles avec la structure de données de l'ancien systeme(ce qui serait dommage), soit c'est un ensemble de moulinettes pour adapter les données qu'il faudra faire en fonction des plugins et de l'ancien systeme (en ce qui concerne Agora, principalement les mots clés, peut etre la gestion de versions pour les modifs en cours, quelques champs statut ... quoi d'autre ?).
D'ailleurs, on a pour le moment pas de mecanisme tout fait pour gerer les mises à jour des plugins eux meme.
Ca serait peut etre pas bete de mettre en place rapidement une gestion de version des plugins en y integrant la notion de migration, pas uniquement celle des mises à jour.
Mais pour revenir à Agora, de toutes facons, essayer de refaire à l'identique serait une grave erreur.
Aujourd'hui Spip peut beaucoup plus, une migration sans amelioration, ca serait (encore) de l'argent jeté par les fenetres.
enfin ce que j'en dis ...
Stephane LAURENT <sl <at> adequates.com> writes:
dlatr a écrit :
> Le 19 août 06, à 20:48, Stephane LAURENT a écrit :
>
>> Non, plus serieusement, le fait que ces fonctionnalités aient été
>> couvertes par Agora me parait anecdotique, je ne vois pas l'utilité de
>> mettre ces plugins à part.
>
> plus sérieusement, un kit de conversion (si j'ose dire:) à spip 2.x
> pour les agoraistes. Sans pertes de données, fonctionnalités... (c'est
> ramener un peu le loup dans la bergerie, mais bon ce doit être pour la
> beauté du geste)
>Oui, la migration des données, c'est important et ca, et pas forcement
specifique à Agora (passage d'un plugin à un autre par exemple ou
migration depuis une contrib vers un plugin).
Pour info, la restauration des dump xml par spip 1.9 gère maintenant le fait que
que le dump puisse integrer des champs non existants dans la base. Dans ce cas
ils sont ignorés, mais le reste des champs est restauré correctement.
Cela veut dire que l'on peut restaurer une base d'une 1.9+plugins sur une 1.9
sans plugin, meme si des champs ont été ajoutés
<troll>
J'avais meme dit qu'on pouvait du coup restaurer un dump agora, mais comme agora
semble pas permettre d'exporter le dump xml, c'est dur a verifier ...
</troll>
Ce qu'il manque encore pour etre complet, c'est d'embarquer la structure des
tables dans le dump pour que la restauration recree les tables inexistantes.
Mais c'est un peu chaud comme truc car il faut alors gerer les conflits,
notamment, si un champ manque dans une table existante, faut il le creer car
c'est un ajout, ou s'abstenir car il a été supprimé lors d'un changement de
version ?
Mais soit ce sont des plugins qui se mettent comme contrainte d'etre
compatibles avec la structure de données de l'ancien systeme(ce qui
serait dommage), soit c'est un ensemble de moulinettes pour adapter les
données qu'il faudra faire en fonction des plugins et de l'ancien
systeme (en ce qui concerne Agora, principalement les mots clés, peut
etre la gestion de versions pour les modifs en cours, quelques champs
statut ... quoi d'autre ?).
D'ailleurs, on a pour le moment pas de mecanisme tout fait pour gerer
les mises à jour des plugins eux meme.
tout fait non, mais le plugin peut utiliser le meme type de gestion de version
de base que le fait spip. Je fais ca dans la plupart de mes plugins :
- une meta version plugin
- des requetes de mise a jour de la base
Pour l'exemple, le plugin forms gere meme la montée de version depuis la contrib
existante en 1.8.
Ca serait peut etre pas bete de mettre en place rapidement une gestion
de version des plugins en y integrant la notion de migration, pas
uniquement celle des mises à jour.Mais pour revenir à Agora, de toutes facons, essayer de refaire à
l'identique serait une grave erreur.
Aujourd'hui Spip peut beaucoup plus, une migration sans amelioration, ca
serait (encore) de l'argent jeté par les fenetres.enfin ce que j'en dis ...
Mais soit ce sont des plugins qui se mettent comme contrainte d'etre compatibles avec la structure de données de l'ancien systeme(ce qui serait dommage), soit c'est un ensemble de moulinettes pour adapter les données qu'il faudra faire en fonction des plugins et de l'ancien systeme (en ce qui concerne Agora, principalement les mots clés, peut etre la gestion de versions pour les modifs en cours, quelques champs statut ... quoi d'autre ?).
D'ailleurs, on a pour le moment pas de mecanisme tout fait pour gerer les mises à jour des plugins eux meme.tout fait non, mais le plugin peut utiliser le meme type de gestion de version
de base que le fait spip. Je fais ca dans la plupart de mes plugins :
- une meta version plugin
- des requetes de mise a jour de la base
Pour l'exemple, le plugin forms gere meme la montée de version depuis la contrib
existante en 1.8.
L'idée c'etait de gerer automatiquement le meta de version des plugins.
A la detection des plugins, chercher la version et si elle est differente de celle en memoire, regarder si une methode existe et l'appeler le cas echeant.
Donc en gros, si à la version 1.3, j'introduis une modif de la base, je dois fournir une methode upgrade_1.3()
Si je viens d'une version 1.1, le systeme cherche
upgrade_1.2() puis upgrade_1.3()
J'imaginais une methode install_XX en plus pour les installs.
C'est cette methode qui pourrait gerer les importations depuis un autre systeme (mais il faut etre capable de detecter l'ancien systeme)
Voila, c'etait juste une idée comme ca.
@++
