Bonjour,
ledit plugin est décrit ici
http://thierry.schmit.free.fr/spip/spip.php?article2
- S'il interesse qqn: servez vous
- si vous estimez qu'il mérite une contrib faîtes le moi savoir
merci pour SPIP
thierry
thierry a écrit :
Bonjour,
ledit plugin est décrit ici
Présentation d’humains - SPIP-Contrib- S'il interesse qqn: servez vous
- si vous estimez qu'il mérite une contrib faîtes le moi savoirmerci pour SPIP
thierry
Bonjour thierry,
je suis allé voir ton plugin, maintenant qu'il est fini,
permets moi de te faire qqs remarques le conçernant en espérant que cela soit constructif pour tous!
Tu émets des doutes quand à la méthode utilisée et je pense que tu as pointé là ce qui pêche,
en même temps, ç'est intéressant de savoir comment tu as proçédé, je veux dire, comment en es tu arrivé au choix de cette méthode et après quelles recherches?
Il y a des tas de sources et de forums d'entraide pour savoir comment faire sur spip, aurais tu été trop vite, as tu formuler clairement ton projet sans avoir de réponses?
Car vois tu, il me semble que toute cette énergie à faire ce plugin aurait été investi dans des projets déjà existants tout le monde y aurait gagné.
C'est vrai que les personnes qui expérimentent spip n'osent pas toujours demander et essaye d'abbord seules, tout le mérite à elles, car après comme tu le dis, tu sais mieux ce qu'il faudra faire et tu sauras à peu près quelle voie prendre dans les rouages de SPIP pourtant je pense qu'il ne faut pas hésiter à demander de l'aide!
Même si ton plugin a le mérite de tester les dernières possibilités du système des plugins mais, pour faire court, lors d'un développement il est important que le plugin puisse être porté par d'autres et que d'autres te porte, chacun ainsi contribue à une amélioration commune de SPIP.
A ce propos, il y a un article HLigne sur les règles de programmation SPIP, un peu ardu pour juste un plugin mais ou je relève "La philosophie du logiciel libre est d’être utilisé dans un maximum de contextes différents, en conséquence le code doit être écrit dans une optique de réutilisation en dehors de son contexte initial de développement."
SPIP que je pense important de rendre publique.
Voilou!
touti
Pour ton info, comme toi, je suis simple utilisateur/contributeur de SPIP, ce que je dis n'engage que moi 
Bonjour thierry,
Bonjour toutati
je suis allé voir ton plugin, maintenant qu'il est fini,
permets moi de te faire qqs remarques le conçernant en espérant que cela
soit constructif pour tous!
merci d'avance
Tu émets des doutes quand à la méthode utilisée et je pense que tu as
pointé là ce qui pêche,
en même temps, ç'est intéressant de savoir comment tu as proçédé, je
veux dire, comment en es tu arrivé au choix de cette méthode et après
quelles recherches?
L'objectif est une présentation homogène de données selon les type des
données.
Ici, par exemple, des diplômes et des expériences professionnelles.
Faisable par articles, mais avec des contraintes dures sur le formalisme
de rédaction des articles et une perte des données pour des tris ou
autres traitements. Enfin pas exactement perte, mais une complexité
accrue pour rechercher toutes les personnes ayant telle qualification
par exemple. Il faudrait alors travailler sur la table spip_articles
avec des like ou autres expressions régulières ce qui ne me semblait pas
optimale en termes de performances.
De plus, pour plusieurs personne ayant la même qualification, il faut
que celle ci soit présentée de la même manière pour toutes les personnes. Il faut donc que cette qualification soit saisie de la même manière dans l'article.
Aux contraintes formelles (mise en page de l'article) s'ajouteraient
alors des contraintes fonctionnelle (identification du type de données
et des données elles même). Avec des articles je me serais donc retrouvé
à mélanger le fond et la forme dans un même objet (article).
Il y a des tas de sources et de forums d'entraide pour savoir comment
faire sur spip, aurais tu été trop vite, as tu formuler clairement ton
projet sans avoir de réponses?
J'ai eu des réponses et j'ai parfois posé dans le vide des questions qui
m'ont aidé à réfléchir. Mais globalement l'accueil fût bon.
Car vois tu, il me semble que toute cette énergie à faire ce plugin
aurait été investi dans des projets déjà existants tout le monde y
aurait gagné.
Oui heu mais.... elle se serait pas faite toute seule ma présentation
d'équipe :).
Ceci étant, comme tu le précises après, j'ai beaucoup appris. Ce qui me donnera peut être l'occasion de rendre à SPIP ce que SPIP m'a donné.
SPIP que je pense
important de rendre publique.
Je l'avais lu (enfin parcouru pour être tout à fait honnête) celui là, et je crois m'y être conformé le plus possible, non ?
Voilou!
touti
Pour ton info, comme toi, je suis simple utilisateur/contributeur de
SPIP, ce que je dis n'engage que moi
encore merci
Donc pour conclure je ne crois pas que, relativement à mon besoin, il y
ait une autre solution que le plugin.
Par contre je suis bien d'accord quand tu dis qu'il faut que le code
soit réutilisable.
J'ai d'ailleurs songé un temps à étendre la gestion des auteurs pour
leur adjoindre mes données, mais j'ai conclu que si un auteur est un
humain, tous les humains ne sont pas des auteurs, ni même des visiteurs.
L'étape suivante de mon plugin va être de rendre les humains et les
auteurs associables en ajoutant un champs id_auteur à la table spip_humains.
A termes j'ai rêvé d'une gestion de carnet d'adresses pluginable à SPIP.
Mais:
- si un tel projet avait un sens il serait amha déjà initié
- si un tel projet naissait il devrait passer par une phase de
spécification il me semble et là j'avais pas le temps de concerter.
@+
thierry
A termes j'ai rêvé d'une gestion de carnet d'adresses pluginable à SPIP.
Mais:
- si un tel projet avait un sens il serait amha déjà initié
- si un tel projet naissait il devrait passer par une phase de
spécification il me semble et là j'avais pas le temps de concerter.
Je dois justement bosser la dessus avec une recherche associée a ce "carnet d'adresse", éventuellement si on pouvait réunir un petit groupe pour faire un plugin le mieux possible je suis plus que partant !!! 
(plutot que de faire ca dans mon coin de le publier et que personne ne l'utilise car ca colle pas aux besoins)
Je dois justement bosser la dessus avec une recherche associée a ce "carnet d'adresse", éventuellement si on pouvait réunir un petit groupe pour faire un plugin le mieux possible je suis plus que partant !!!
Pour quelle genre d'application ?
thierry a écrit :
Je dois justement bosser la dessus avec une recherche associée a ce "carnet d'adresse", éventuellement si on pouvait réunir un petit groupe pour faire un plugin le mieux possible je suis plus que partant !!!
Pour quelle genre d'application ?
c'est pour 2 sites : un site internet d'une communauté de commune et un site d'une mairie
c'est pour 2 sites : un site internet d'une communauté de commune et un site d'une mairie
c'est bien à ce genre d'application que je pensais
tu as donc besoin d'une gestion d'adresses associable à
1/- des humains
2/- des entités légales de types commerçants, associations,
services de santé....
non ?
mais quand même... pq les articles te suffisent pas ?
thierry a écrit :
c'est pour 2 sites : un site internet d'une communauté de commune et un site d'une mairie
c'est bien à ce genre d'application que je pensais
tu as donc besoin d'une gestion d'adresses associable à
1/- des humains
2/- des entités légales de types commerçants, associations,
services de santé....non ?
c'est tout a fait ca, dans l'esprit.
mais quand même... pq les articles te suffisent pas ?
et bien en fait oui et non , mais toujours pareil pour éviter d'utiliser a tout bout de champ les champs extra je comptais avoir une table suplémentaire qui contiendrai les entités de type adresse. cette table pourrait etre relié aux rubriques et éventuellement mais je vois pas trop l'intéret aux articles. Eviter les champs ca permet de faire des recherches plus simplement...
le but étant d'utiliser les rubriques comme des thèmes de mon annuaire : ex: commercants , écoles , mairies , services de mairies,...
avec plusieurs niveaux bien sur dans les rubriques, permettant un classement au plus fin.
Je ne veux pas utiliser les mots clefs pour cette fonctionnalité, car les mots clefs servent un peu a tout faire dans des gros sites et du coup déjà moi je fini par avoir du mal en terme d'utilisabilité alors j'imagine même pas la <troll>secrétaire ( blonde) de mairie </troll> qui va saisir une info ...
donc je n'ai pas encore débuté mais mon cahier des charges est assez précis ... je dois finir ca pour fin de semaine prochaine ...en gros
mon plus gros probléme est que je n'ai pas encore capté comment faire cela en plugin (jamais fait de plugins encore)... je vais regardé le tien ca aidera
éventuellement si on peut déjà étoffer ces besoins la pour en retranscrire quelque chose d'utilisable pour le plus grand nombre ca serait la premiére étape.
fin de la semaine prochaine ça fait rapide pour devel un plugin
bien stable et tout.
sinon je viens de découvrir
http://www.spip-contrib.net/?Plugin-Auteurs-Complets
qui peut etre te suffirait
tu as pas mal de sites utilisant SPIP sur http://www.spip.net
ça pourrait te donner des idées.
Sinon l'appellation plugin correspond à quelque chose de bien intégré
dans SPIP et un minimum réutilisable par autrui
Dans ton cas il est toujours possible d'ajouter une table à la base SPIP
et de l'utiliser directement dans des boucles. La mise à jour de la table se fera alors via phpMyAdmin le temps que tu intégres le plugin
gérant la table à spip. Pour faire ça tu as aussi le plugin
tableData.
Mais maintenant que j'y pense ça devient incompatible avec ta secrétaire
de mairie qui doit saisir les données.
thierry a écrit :
fin de la semaine prochaine ça fait rapide pour devel un plugin
bien stable et tout.
quand t'es a 100% du temps dessus je pense que ca doit-être faisable ... je pars pas de zéro non plus dans le dév autour de spip 
sinon je viens de découvrir
Plugin Auteurs Complets (obsolète) - SPIP-Contrib
qui peut etre te suffirait
je vais y jeter un coup d'oeil
Sinon l'appellation plugin correspond à quelque chose de bien intégré
dans SPIP et un minimum réutilisable par autrui
je veux juste pouvoir l'utiliser sur plusieurs versions de spip un des sites sera en spip 1.9.1 et l'autre probablement en 1.9.2
puis pour faire évoluer ses sites aux fils des versions de spip vaut mieux faire ca en plugin... puis pourquoi pas
Dans ton cas il est toujours possible d'ajouter une table à la base SPIP
et de l'utiliser directement dans des boucles. La mise à jour de la table se fera alors via phpMyAdmin le temps que tu intégres le plugin
gérant la table à spip. Pour faire ça tu as aussi le plugin
tableData.
j'avais déja essayer mais j'avais pousser plus que ca ... je vais voir la dernière version car celle que j'avais utilisé date un peu maitenant
Mais maintenant que j'y pense ça devient incompatible avec ta secrétaire
de mairie qui doit saisir les données.
m'en parle pas
Yoann NOGUES a écrit :
thierry a écrit :
fin de la semaine prochaine ça fait rapide pour devel un plugin
bien stable et tout.
quand t'es a 100% du temps dessus je pense que ca doit-être faisable ... je pars pas de zéro non plus dans le dév autour de spip
sinon dans mon plugin tu n'as en fait besoin de des tables
spip_humains, et
spip_humains_adresses
je dirais
donc tu peux dégager tout ce qu'il y a autour
et tu auras un équivalent moins aboutit de "auteurs complets"
Le repoche que je me permets, du bas de mes petites compétences,
de faire à "auteurs complets" c'est que dans sa version actuelle
il altère la table spip_auteurs, donc le coeur de SPIP.
j'ai laissé la fonction d'import xml, mais elle est pas du tout documentée
sinon le modèle de la table adresse laisse à désirer si tu veux
intégrer toutes les adresses des communes dans ton site. Meme sans ça il laisse à désirer d'ailleurs.
idéalement je pense qu'il faudrait lier un humain à un identifiant d'adresse
une adresse étant elle meme un enregsitrement dans une table adresses:
- un numéro au sens large du terme 1, 1bis, la jolie ferme....
- un identifiant de rue
une rue étant un enregistrement dans une table rues
- identifiant de rue
- identifiant de ville
- nom de rue
une ville étant un enregistrement dans une table villes
- identifiant de ville
- identifiant de département/etat
- nom de ville
un département/état étant un enregistrement dans une table departements
- identifiant de departement
- identifiant de pays
- nom de departement
un pays étant un enregistrement dans une table pays
- identifiant de pays (deux lettres)
(- identifiant de planète)
- nom de pays
etc...
mais ça je ne sais pas (encore) l'intégrer à SPIP
thierry a écrit :
Le repoche que je me permets, du bas de mes petites compétences,
de faire à "auteurs complets" c'est que dans sa version actuelle
il altère la table spip_auteurs, donc le coeur de SPIP.
Au cas ou ca interesse ....
Le plugin profil_etendu gere des tables de profil pour les auteurs.
Selon le parametrage (calqué sur le parametrage des champs extras), il va créer la ou les tables, en y ajoutant les champs id_auteur et maj.
par defaut ca sera la table spip_profil_etendu mais ca peut gerer plusieurs tables avec des formulaires indépendants
Le formulaire #FORMULAIRE_PROFIL_ETENDU genere le form correspondant et gere les enregistrements.
Ca reprend egalement le formulaire d'inscription pour y ajouter l'ensemble des champs du profil.
Il y meme la possiblité de "brancher" des formulaires de F&T dessus, en mettant par exemple un radio bouton et en proposant un formulaire ou un autre en fonction du choix.
Après, pour afficher les données, ben c'est tout simple puisue c'est une table avec id_auteur comme identifiant.
Je sais que j'ai pas beaucoup communiqué dessus et qu'il n'est pas bien fini, mais bon, il existe.
mes 2 sous.
@++
Au cas ou ca interesse ....
Le plugin profil_etendu gere des tables de profil pour les auteurs.
tout m'interesse, mais celui la je le trouve pas ?
il est sur contrib ?
thierry a écrit :
Au cas ou ca interesse ....
Le plugin profil_etendu gere des tables de profil pour les auteurs.
tout m'interesse, mais celui la je le trouve pas ?
il est sur contrib ?
Le 19 mai 07, à 23:44, thierry a écrit :
Bonjour,
ledit plugin est décrit ici
Présentation d’humains - SPIP-Contrib
- S'il interesse qqn: servez vous
- si vous estimez qu'il mérite une contrib faîtes le moi savoir
salut
et bien à la relecture, et compte tenu aussi de toutes les réflexions en cours sur le sujet des auteurs, il me semble thierry qu'il serait intéressant de publier tes travaux sur spip-contrib. A minima cela donne un bon exemple d'un besoin en ce domaine. Cela me parait d'autant plus souhaitable que tu as déjà rédigé quelque chose. A partir de la, si tu en est d'accord, à ton choix :
- soit tu reprends tout ton article et le place sur spip-contrib
- soit u reprends une présentation générique sur contrib et renvoi sur ton article pour le reste
dans les deux cas cela sera dans cette rubrique "http://www.spip-contrib.net/Authentification-et-securite"
@+ NicolasR
nicolasriq@free.fr a écrit :
dans les deux cas cela sera dans cette rubrique "http://www.spip-contrib.net/Authentification-et-securite"
Merci pour ton avis favorable.
J'ai cependant un doute sur la localisation de la contrib.
En effet je n'ai pas pensé ce plugin comme une extension des auteurs, même si j'ai rajouté un champ id_auteur dans la table humains
pour permettre d'accéder aux données du plugin dans une boucle AUTEURS.
(En cela il est redondant avec auteurs_complets).
L'objet de ce plugin, tel que je le voulais, était de pouvoir gérer des humains comme du contenu à publier avec, au bout du tunnel, les pages jaunes ou les pages blanches.
D'un autre coté je ne vois pas trop ou le mettre ailleurs... à part Rédaction, mais ça ne me semble pas adapté non plus. Il faudrait une rubrique Contenus en fait, mais il y serait bien seul
Donc si avec ces précisions tu penses toujours qu'il doit être dans Authentification-et-securite, c'est là que je finirais par le mettre.
@+
thierry
Le 2 juin 07, à 00:04, thierry a écrit :
J'ai cependant un doute sur la localisation de la contrib.
.. D'un autre coté je ne vois pas trop ou le mettre ailleurs... à part
Rédaction, mais ça ne me semble pas adapté non plus. Il faudrait une
rubrique Contenus en fait, mais il y serait bien seul
en fait l'arborescence n'est pas forcément figé, mais pour qu'elle évolue cela se fait de manière pragmatique : si l'on constate que des contribs génèrent logiquement une nouvelle branche alors elle est créée ... mais cela se découvre le plus souvent après leurs mises en ligne. Donc l'idée est de d'abord mettre en ligne dans la structure existante.
Pour ton cas l'idée est pour l'instant tout simplement de regrouper les travaux techniquement centrés sur les auteurs, car il y quelque chose encore un peu confus mais en train d'émerger coté développeurs. Autant que la doc participe à ces convergences. Peut-etre que cela évoluera encore plus tard selon les besoins. L'avantage d'un site SPIP c'est qu'il est souple.
@+ NicolasR