[SPIP Zone] Modif spip-listes

Archives Zone
1

Hello,

Bonne nouvelle d'apprendre que tu souhaites participer à spip-listes. Je compte faire evoluer spip-listes justement ces jours qui viennent et je crois que les autres sont chauds aussi.

Pour participer il faut t'inscrire sur spip-zone, et que tu obtiennes un acces au depot svn. On discute des evolutions de spip listes sur la liste spip-zone@rezo.net (en copie de ce mail), ou sévissent les autres développeurs, principalement : cerdic, toggg, erational et renato.

Pour les evolutions, il y a une todo bordélique sur le site ici
http://bloog.net/spip.php?article115 et des bugs remontés sur le forum

Pour faire sauter les champs extra, nous avons envisager de faire porter le format de reception par la table spip_auteurs_listes. Ca permettrait en sus d'envisager d'utiliser une autre table que spip_auteurs pour gérer la liste des destinataires.

Dis-nous ou tu en es avec spip-listes qu'on puisse discuter plus efficacement.

BoOz

elrik75@free.fr a écrit :

Bonjour,

J'envisage de faire des modifications à spip-listes - et si possible de
contribuer pour éviter un fork.

Celà dit j'aurais qq questions à poser sur les évolutions possibles /
souhaitées ; si des choses sont déjà prévues...

Je voudrais par exemple supprimer l'itilisation du champ extra de
"spip_auteur".

Sur le SVN, peu de choses évoluent en ce moment, est-ce voulu ou est-ce un
manque de temps ?

Serait-il possible de rentrer en contact plus directement ?

Merci ! (et félicitation)

-- Envoi via le site bloOg (http://bloog.net/) --

2

BoOz a écrit :

Pour faire sauter les champs extra, nous avons envisager de faire
porter le format de reception par la table spip_auteurs_listes. Ca
permettrait en sus d'envisager d'utiliser une autre table que
spip_auteurs pour gérer la liste des destinataires.

Dis-nous ou tu en es avec spip-listes qu'on puisse discuter plus
efficacement.

J'ai une bonne vue de la base de données. J'ai déjà fait qq modifs pour :

1- placer les date inscription dans spip_auteur_liste
2- l'email de d'information devient un email de validation quand on
clique dessus.
3- qq modif cosmétiques dans l'interface

Et j'ai plein d'idées d'amélioration...

Par contre l'utilisation des champs extra cradent le code méchamment...

Il faudrait une table spip_auteur_extra avec id_auteur_extra = id_auteur
où on mettrait nos éléments. On pourrait alors faire des "vraies" requêtes.

Il faudrait créer une API spip_liste pour permettrent aux developpeurs
(et à nous) une utilisation plus facile.

Ceci sont des exemples :
fonction demande_inscription (email, list_id, nom, prenom)
fonction validation_inscription(cookie, list_id)
fonction envoi_email_inscrition(auteur_id)

Avec des arguments optionnels, un peu de polymorphisme, on peu faire des
truc sympas.
Le code actuel n'est pas très ré-utilisable pour un développeur, il est
disséminé un peu partout, avec des variables globales à la pelle. Pour
moi qui ne connait pas trop SPIP, c'est difficile de comprendre alors
que le code est propre. C'est donc (je pense) qu'il manque de structure.

Pour moi le plus important reste la suppression des champs extras ! Il
faut donc réfléchir à un base propre qui correspondent à la majorité des
besoins.

Guillaume

BoOz

elrik75@free.fr a écrit :

Bonjour,

J'envisage de faire des modifications à spip-listes - et si possible de
contribuer pour éviter un fork.

Celà dit j'aurais qq questions à poser sur les évolutions possibles /
souhaitées ; si des choses sont déjà prévues...

Je voudrais par exemple supprimer l'itilisation du champ extra de
"spip_auteur".

Sur le SVN, peu de choses évoluent en ce moment, est-ce voulu ou
est-ce un
manque de temps ?

Serait-il possible de rentrer en contact plus directement ?

Merci ! (et félicitation)

-- Envoi via le site bloOg (http://bloog.net/) --

3

Pour moi le plus important reste la suppression des champs extras ! Il
faut donc réfléchir à un base propre qui correspondent à la majorité des
besoins.

L'API de extra est potable, mais c'est son mode de stockage par défaut
qui est trop basique. Il "suffirait" de remplacer ecrire/inc/extra.php
par quelque chose qui stocke au bon endroit ; c'est en germe aussi
dans le plugin cfg.

-- Fil

4

Guillaume Savary (Elrik) a écrit :

BoOz a écrit :

Pour faire sauter les champs extra, nous avons envisager de faire
porter le format de reception par la table spip_auteurs_listes. Ca
permettrait en sus d'envisager d'utiliser une autre table que
spip_auteurs pour gérer la liste des destinataires.

Dis-nous ou tu en es avec spip-listes qu'on puisse discuter plus
efficacement.
   
J'ai une bonne vue de la base de données. J'ai déjà fait qq modifs pour :

1- placer les date inscription dans spip_auteur_liste

Excellent, n'hésite pas à commiter sur le svn.

2- l'email de d'information devient un email de validation quand on
clique dessus.

Bonne idée également, tu peux le commiter ca fera plaisir à certains qui demandent cette fonctionalité.

3- qq modif cosmétiques dans l'interface

Fais péter !

Et j'ai plein d'idées d'amélioration...

Excellent.

Par contre l'utilisation des champs extra cradent le code méchamment...

Il faudrait une table spip_auteur_extra avec id_auteur_extra = id_auteur
où on mettrait nos éléments. On pourrait alors faire des "vraies" requêtes.

Oui, c'est exactement la piste que nous suivons de manière générale sur spip-zone en ce moment. Ceci concerne en effet les plugins spip-listes, gestion d'une association, auteurs complets, et en fait tous les plugins avec des auteurs.

On en discute ici et sur irc avec Toggg, kent1, azertuyi, cmmt notament. L'idée serait de s'appuiyer sur les nouvelles possibilités du plugin cfg qui vient d'etre adapté en ce sens (storage dans des champs naturels de la bdd tel que tu l'as décrit).

Je te suggere de te greffer sur ce travail là.

Il faudrait créer une API spip_liste pour permettrent aux developpeurs
(et à nous) une utilisation plus facile.

Ceci sont des exemples :
fonction demande_inscription (email, list_id, nom, prenom)
fonction validation_inscription(cookie, list_id)
fonction envoi_email_inscrition(auteur_id)

Je suis 100% d'accord avec toi, c'est cool non ? donc go, go, go, commite !

BoOz

5

Fil a écrit :

Pour moi le plus important reste la suppression des champs extras ! Il
faut donc réfléchir à un base propre qui correspondent à la majorité des
besoins.

L'API de extra est potable, mais c'est son mode de stockage par défaut
qui est trop basique. Il "suffirait" de remplacer ecrire/inc/extra.php
par quelque chose qui stocke au bon endroit ; c'est en germe aussi
dans le plugin cfg.

-- Fil

Précision : je parlais ici du champs extra de "spip_auteur".
Le problème, justement est que nous avons besoin d'une API pour gérer le
champ extra alors que cela devrait ne pas exister et faire partie des
requêtes sql standards !

Exemple : je veux savoir qui est abonné en mode HTML : impossible !
Je dois d'abord récupéré tout le monde puis dé-serializer extra pour
chacun et regarder s'il est abonné en HTML !
C'est sale au niveau base, sale au niveau code (même si l'API est très
bien) et ça coûte des ressources.
Bref, je ne pense pas que cela soit rentable.

6

BoOz a écrit :

Guillaume Savary (Elrik) a écrit :

BoOz a écrit :

Pour faire sauter les champs extra, nous avons envisager de faire
porter le format de reception par la table spip_auteurs_listes. Ca
permettrait en sus d'envisager d'utiliser une autre table que
spip_auteurs pour gérer la liste des destinataires.

Dis-nous ou tu en es avec spip-listes qu'on puisse discuter plus
efficacement.
  
J'ai une bonne vue de la base de données. J'ai déjà fait qq modifs
pour :

1- placer les date inscription dans spip_auteur_liste

Excellent, n'hésite pas à commiter sur le svn.

2- l'email de d'information devient un email de validation quand on
clique dessus.

Bonne idée également, tu peux le commiter ca fera plaisir à certains
qui demandent cette fonctionalité.

3- qq modif cosmétiques dans l'interface

Fais péter !

Et j'ai plein d'idées d'amélioration...

Excellent.

Par contre l'utilisation des champs extra cradent le code méchamment...

Il faudrait une table spip_auteur_extra avec id_auteur_extra = id_auteur
où on mettrait nos éléments. On pourrait alors faire des "vraies"
requêtes.

Oui, c'est exactement la piste que nous suivons de manière générale
sur spip-zone en ce moment. Ceci concerne en effet les plugins
spip-listes, gestion d'une association, auteurs complets, et en fait
tous les plugins avec des auteurs.

On en discute ici et sur irc avec Toggg, kent1, azertuyi, cmmt
notament. L'idée serait de s'appuiyer sur les nouvelles possibilités
du plugin cfg qui vient d'etre adapté en ce sens (storage dans des
champs naturels de la bdd tel que tu l'as décrit).

Je te suggere de te greffer sur ce travail là.

Il faudrait créer une API spip_liste pour permettrent aux developpeurs
(et à nous) une utilisation plus facile.

Ceci sont des exemples :
fonction demande_inscription (email, list_id, nom, prenom)
fonction validation_inscription(cookie, list_id)
fonction envoi_email_inscrition(auteur_id)

Je suis 100% d'accord avec toi, c'est cool non ? donc go, go, go,
commite !

BoOz

Le problème majeur est que mes modifs dépendent du modèle de base actuel
car je n'ai pas voulu "casser" le plugin.
Je préférerais commiter des modifs après changement de la base, ca me
demandrait moins de travail. (je bosse sur mon temps libre comme bcp)
Mais si tu penses que ca vaut le coup, je peux nettoyer un peu et
documenter ce que j'ai fait.
Comment fonctionne le SVN ? Il y a des branches de dev ? QQun relit le
code ?

7

Guillaume Savary (Elrik) a écrit :

Pour le format, comme je te l'ai dit, nous envisageaons de le faire
porter par la table spip_auteurs_listes via le plugin cfg. Pour le
désabonnement, je pense qu'il faudrait virer la possibilité
(historique mais perturbante) d'etre abonné à zero liste, et ainsi
désabonner une personne reviendrait à l'enlever de toutes les listes,
bref cette information ne serait plus définie dans un champs extra.
   
Ok, j'ai compris maintenant :wink: Ca me parait bien, si ce n'est que ce
n'est pas en forme normale : pour chaque abonnement on va répéter HTML
ou TEXT.

Oui, ce n'est peut etre pas idéal mais ca presente l'avantage d'etre directement operationnel sans modifier la base.

Il est vrai que dans le cas général des autres plugins (auteurs_complets, gestion d'une association), on envisage de créer pour les infos supplementaires relatives aux auteurs une table genre spip_auteurs_extras avec dedans les infos complementaires. La structure de cette table serait définie / synchronisée via CFG avec les champs du formulaire HTML de saisie. C'est ca l'idée du plugin CFG : la structure des formulaires HTML de saisie définit les champs dans la table.

Peut etre qu'on ferait mieux de se caler sur ce système la pour spip listes si on concerve des champs supplémentaires : le format (html / texte) et l'abonnement (oui / non).

BoOz