A lire
http://www.urec.cnrs.fr/rubrique243.html
http://www.urec.cnrs.fr/IMG/pdf/LL.PLUME_Choix_Drupal.pdf
-- Fil
Fil a écrit :
A lire
http://www.urec.cnrs.fr/rubrique243.html
http://www.urec.cnrs.fr/IMG/pdf/LL.PLUME_Choix_Drupal.pdf
Encore un soucis de comm' on dirait :
Page 13/14 : 'Il lui manque encore quelques fonctionnalités indispensables au projet PLUME (notament la possibilité de gérer des champs externes car les "champs extra" ne sont qu'une astuce technique mais peu pérenne et techniquement limité.'
C'est trop bête de constater qu'on parle encore de champ extra quand on connait les possibilités d'extensions de tables, champs et bases SQL qu'on peut mettre en oeuvre aujourd'hui avec SPIP.
Et je ne me suis arrêté que là-dessus...
C'est trop bête de constater qu'on parle encore de champ extra quand on
connait les possibilités d'extensions de tables, champs et bases SQL
qu'on peut mettre en oeuvre aujourd'hui avec SPIP.
On peut vraiment ? Si tu ajoutes un champ aux articles, il n'apparait
pas dans l'espace privé, ne fonctionne pas avec les crayons etc. Il
reste du boulot donc. ca devrait plutôt nous motiver, en fait, à
finir les trucs qui manquent 
Ce que je trouve dommage c'est qu'il ne soit pas venu demander où on
en était sur les "points faibles" qu'il a analysés ; comme si ce
n'était pas du logiciel libre, mais le choix d'un client parmi des
produits sur étagère.
-- Fil
Il faudrait peut être faire une réponse motivée expliquant pourquoi SPIP reste le meilleur choix possible.
Et pourquoi ils se trompent sur les limites de SPIP.
Ca serait dommage de perdre le marché de la Recherche et de la Fac;)
Je pense aussi que c'est juste un "manque de com" qui a pu aboutir à ce choix de Drupal.
Il faudrait peut être faire une réponse motivée expliquant pourquoi
SPIP reste le meilleur choix possible.
Et pourquoi ils se trompent sur les limites de SPIP.
Je crois qu'ils ne se trompent pas, ils ont fait une analyse objective
de SPIP 1.9.2.
Ca serait dommage de perdre le marché de la Recherche et de la Fac;)
Le quoi ?
Je pense aussi que c'est juste un "manque de com" qui a pu aboutir à
ce choix de Drupal.
On n'a jamais fait de comm', je crois. Et à mon avis c'est aussi bien
comm' ça. En revanche on peut toujours faire de la meilleure doc.
Quand je vois les urls cités dans le rapport, j'ai comme un malaise.
Ce rapport souligne des faiblesses de SPIP. On peut s'en offusquer ou
s'en fiche ; on peut regretter que le CNRS soit aussi "consommateur"
et pas plus impliqué ; on peut aussi constater que ça tombe bien, ces
points faibles sont aussi ce sur quoi on est en train de travailler.
-- Fil
Fil a écrit :
Il faudrait peut être faire une réponse motivée expliquant pourquoi
SPIP reste le meilleur choix possible.
Et pourquoi ils se trompent sur les limites de SPIP.
Je crois qu'ils ne se trompent pas, ils ont fait une analyse objective
de SPIP 1.9.2.
oui, et en plus, il faut bien avoir en tete que c'est une évaluation face à un besoin spécifique : le leur.
Par exemple, la note de sécurité n'est pas une évaluation de la solidité de l'outil (j'ai pas vu pourquoi Spip prenait 3, ils n'avaient sans doute pas vu certains plugins).
Maintenant, pour parler de "comm", il manque sans doute un récapitulatif fonctionnel de ce qu'on peut faire en standard, avec tel ou tel plugin et en développant un peu (ajout de parametres/fonctions surchargeables / formulaires publics/...).
Mais bon, il suffit de poser la question pour avoir la réponse... donc je ne pense pas que ca manque beaucoup aux utilisateurs.
Par contre, les réponses évoluent à mesure que Spip se développe, donc capitaliser les reponses sur une page recap (wiki ?), ca n'a d'interet que si c'est maintenu, sinon ca peut meme avoir l'effet inverse.
mes 2 sous.
@++
Je crois qu'ils ne se trompent pas, ils ont fait une analyse objective de SPIP 1.9.2.
je trouve aussi ... la précision "1.92" étant importante, vu ce qui est en germe avec avec la 1.93g à venir (une sorte de pré 2.0 si j'ai bien compris) . Un autre point intéressant de cette étude bien argumenté (et quand même pas si défavorable à SPIP) est que cela donne une vision extérieure, non seulement du code de SPIP lui même, mais aussi de ce qui peut en être compris rapidement via sa documentation, et par des utilisateurs déjà connaisseurs et plutôt favorable à SPIP en plus.
... En revanche on peut toujours faire de la meilleure doc.
J'aime bien la précision "meilleure", et pas seulement "plus" (quoique cela soit aussi nécessaire parfois). Une des choses qui pèche actuellement à mon avis c'est le manque (ou un manque de finition) des liants et de point de repères d'analyse rapide rapidement accessibles, qui permette de naviguer avec un effort raisonnable entre tous les éléments. Qui permette à chacun de se dire, selon ses besoins, "ceci me concerne", "j'ai ou je n'ai pas besoin de me pencher sur cela", "je peux commencer simplement comme ceci et faire plus tard cela", etc... . Une fois ce tri fait je pense que tout le monde accepte d'avoir à creuser plus avant les sujets qui l'intéresse, mais on ne peut pas demander à tout le monde de creuser tous les sujets simplement pour se repérer.
Il manque tout autant des clefs de lecture pour les nouveaux venus que de la masse de documentation. C'est un vrai effort de faire cela, et cela ne peut être le fait du seul noyau des développeurs (qui ont déjà le code à assumer). Clairement, arriver à augmenter le nombre des documentalistes non développeurs est aussi un enjeu.
Ce rapport souligne des faiblesses de SPIP. On peut s'en offusquer ou s'en fiche ; on peut regretter que le CNRS soit aussi "consommateur"
et pas plus impliqué ; on peut aussi constater que ça tombe bien, ces points faibles sont aussi ce sur quoi on est en train de travailler.
En même temps il faudra aussi admettre que les points en développements seront toujours, par définition, jamais aussi bien documentés que les sujets stabilisés. Mais sSimplement en récupérant régulièrement certains mails et en les reformatant sous forme d'article il y aurait déjà pas mal de matériel rédactionnel pour ce faire. Il manque probablement de quelques journalistes vulgarisateurs/trices, suivant régulièrement les échanges de développement et essayant de rendre compte au commun des mortels des tendances (ce qui se fait d'ailleurs dans le monde scientifique).
@+ NicolasR
PS : concernant la visibilité des plugins un chantier accessible est d'essayer d'aboutir l'usage du flux xml de la zone.
Autant c'était le cas pour l'article de Decision Informatique, autant là ça ne l'est pas.
Je trouve cette étude bien menée et les points faibles trouvés dans SPIP exacts QUANT AU BUT VISE.
L'auteur dit bien qu'il a un impératif de temps, et donc ce qu'il veut c'est qqch qui soit le plus proche possible de ce qu'il veut faire, et conçu de telle manière que les ajouts soient rapidement développés et facilement maintenables. Il a besoin de controles d'accès et d'un workflow différents de ceux de SPIP, et dans le tableau de la page 14 on voit bien que c'est là que SPIP perd des points face à Drupal. Et en effet, si on veut changer le processus éditorial (workflow) de SPIP il faut des interventions partout dans le code, pas une simple surcharge d'un script bien déterminé. Rien non plus pour diversifier les accès au forum interne. Je connais le pb car j'ai développé qqch d'analogue pour la gestion d'articles soumis à conférence avec relecteurs s'ignorant mutuellement, c'est galère à maintenir dans l'état actuel de SPIP.
Ce qui est intéressant c'est de remarquer que tout ça est lié à la présence de constantes écrites en dur dans le code, et concernant les champs nommés "statut". Le besoin est de diversifier les statuts que peut prendre un article, un forum et un auteur, et de pouvoir définir quels statuts d'auteurs permettent de donner tel statut à un article et d'intervenir dans un forum d'un certain statut. On a presque fini en ce qui concerne le statut des auteurs, qui est à présent presqu'entièrement confiné dans la bibli "autoriser". Mais pour le statut des articles, on est encore trop grossier, et pour les types de forums c'est borné.
Mon impression (ce n'est encore qu'une impression, hein) c'est que donner les fonctionnalités demandées sans induire un apprentissage spécifique à SPIP pourrait se faire simplement en important le système de droits de SQL dans SPIP. Pour SQL, on peut spécifier pour chaque utilisateur et pour chaque table s'il a le droit de faire chaque opération (INSERT, UPDATE, DELETE, etc). Actuellement un visiteur SPIP a pour seul droit de faire un Insert dans la table des forums, un redacteur de faire un Insert dans la table des articles etc. Ce qui pose pb c'est le champ statut, car on ne peut dire que tel auteur a le droit de lui donner telle valeur. Une solution (et qui répondrait au besoin du CNRS) serait d'avoir autant de tables que de statuts. La table Propositions, par exemple, serait accessible en Insert par les rédacteurs d'un article, et on pourait avoir 2 champs id_article et id_auteur ce qui donnerait l'information supplémentaire sur quel auteur a proposé l'article. La table Publications serait en Insert pour les admin, de nouveau on pourrait savoir qui a pris la décision de publier l'article, etc. A la limite, SPIP pourrait tourner non pas avec un seul utilisateur SQL mais avec autant que d'auteurs SPIP, spip_connect provoquant la connexion SQL au nom de l'auteur authentifié par SPIP. Il faudrait pas mal réorganiser les tables SQL pour en arriver là, mais ça vaut le coup d'y réfléchir.
Committo,Ergo:Sum
Une solution (et
qui répondrait au besoin du CNRS) serait d'avoir autant de tables que
de statuts.
Pas franchement plus souple pour ce qui est de la configuration des
statuts disponible, non ?
La table Propositions, par exemple, serait accessible en
Insert par les rédacteurs d'un article, et on pourait avoir 2 champs
id_article et id_auteur ce qui donnerait l'information supplémentaire
sur quel auteur a proposé l'article. La table Publications serait en
Insert pour les admin, de nouveau on pourrait savoir qui a pris la
décision de publier l'article, etc. A la limite, SPIP pourrait
tourner non pas avec un seul utilisateur SQL mais avec autant que
d'auteurs SPIP, spip_connect provoquant la connexion SQL au nom de
l'auteur authentifié par SPIP.
Ce sera inutilisable sur une grande majorité de sites où le compte
MySQL ne peut pas être choisi, et est forcément unique.
Une solution plus générique, et relativement courante, serait un
automate à états/transitions où les droits sur les transitions
pourraient sans doute être gérés dans autoriser().
Ce n'est pas forcément très compliqué à développer en respectant la
compatibilité ascendante, mais c'est surtout côté interface de
configuration que ça devient compliquer à faire ergonomique...
A la limite, SPIP pourrait
tourner non pas avec un seul utilisateur SQL mais avec autant que
d'auteurs SPIP, spip_connect provoquant la connexion SQL au nom de
l'auteur authentifié par SPIP.Ce sera inutilisable sur une grande majorité de sites où le compte
MySQL ne peut pas être choisi, et est forcément unique.
J'ai dit "à la limite", et si on veut que SPIP soit adopté dans des situations différentes, il ne faut pas s'auto-censurer. Ce ne serait pas le premier bout de code dans SPIP qui serait différent selon les droits offerts par l'hébergeur.
Une solution (et
qui répondrait au besoin du CNRS) serait d'avoir autant de tables que
de statuts.Pas franchement plus souple pour ce qui est de la configuration des
statuts disponible, non ?
...
Une solution plus générique, et relativement courante, serait un
automate à états/transitions où les droits sur les transitions
pourraient sans doute être gérés dans autoriser().Ce n'est pas forcément très compliqué à développer en respectant la
compatibilité ascendante, mais c'est surtout côté interface de
configuration que ça devient compliquer à faire ergonomique...
C'est bien pour ça que contrairement à ce que tu dis la solution que je propose serait "franchement plus souple".
Committo,Ergo:Sum
> Ce sera inutilisable sur une grande majorité de sites où le compte
> MySQL ne peut pas être choisi, et est forcément unique.J'ai dit "à la limite", et si on veut que SPIP soit adopté dans des
situations différentes, il ne faut pas s'auto-censurer. Ce ne serait
pas le premier bout de code dans SPIP qui serait différent selon les
droits offerts par l'hébergeur.
OK
> Une solution plus générique, et relativement courante, serait un
> automate à états/transitions où les droits sur les transitions
> pourraient sans doute être gérés dans autoriser().
>
> Ce n'est pas forcément très compliqué à développer en respectant la
> compatibilité ascendante, mais c'est surtout côté interface de
> configuration que ça devient compliquer à faire ergonomique...C'est bien pour ça que contrairement à ce que tu dis la solution que
je propose serait "franchement plus souple".
Plus souple en termes de développements et configurations techniques,
certes, mais inaccessible au plus grand nombre. Cela me semble
dommage.
Mais non, puisque je propose juste d'organiser les tables SQL différemment tout en gardant la meme interface utilisateur dans la version de base. L'avantage est que les extensions qui voudront remplacer le système de droit actuel pourront le faire plus facilement, et ce sera leur responsabilité de proposer une interface compréhensible. Et ça ne parait pas difficile, car ce ne serait rien de plus qu'une sous-ensemble de PHPMyAdmin.
Committo,Ergo:Sum
Plus souple en termes de développements et configurations techniques,
certes, mais inaccessible au plus grand nombre. Cela me semble
dommage.Mais non, puisque je propose juste d'organiser les tables SQL différemment tout en gardant la meme interface utilisateur dans la version de base. L'avantage est que les extensions qui voudront remplacer le système de droit actuel pourront le faire plus facilement, et ce sera leur responsabilité de proposer une interface compréhensible. Et ça ne parait pas difficile, car ce ne serait rien de plus qu'une sous-ensemble de PHPMyAdmin.
Mais justement, si tu éclates un même contenu dans plusieurs tables pour chaque statut, l'ajout / modification / suppression de statuts va être très pénible, on va vite avoir des plugins qui se marchent sur les pieds entre autres...
-Nicolas
Qui te parle d'éclater un meme contenu ? Il s'agirait de supprimer le champ statut de la table Articles et de dire qu'un article a le statut Truc si son indice apparait dans la table Sratut_Truc. Si plusieurs tables Statut_X contiennent un certain id_article, on prend le plus récent, car ce qu'offre en plus cette architecture c'est d'avoir un historique des statuts successifs, ce qui va dans le sens d'un "workflow" redéfinissable. Il y a une complexité supplémentaire dans le code, mais elle est légère rapportée à la grosse fonctionnalité supplémentaire que ça apporterait.
Committo,Ergo:Sum
Nicolas Hoizey a écrit :
Mais justement, si tu éclates un même contenu dans plusieurs tables
pour chaque statut, l'ajout / modification / suppression de statuts va être très pénible, on va vite avoir des plugins qui se marchent sur les pieds entre autres...
ben non pourquoi ?
La, il s'agit d'utiliser des tables differentes par statut ce qui justement pourrait simplifier grandement la création de plugins.
De toutes facons, les plugins ne devraient pas faire de manip en base mais s'appuyer sur une API, mais c'est un autre probleme...
Je trouve l'idée séduisante mais par contre elle pose un autre probleme : transactionnel !
faire un update ou un insert, si ca plante, c'est pas tres grave.
Si il faut en faire plusieurs, on risque de laisser la base dans un etat inconsistant, vu qu'on ne gere pas les transactions..
En tous cas, ca me parait urgent de mettre en place une API pour toutes les manipulations basiques pour justement pouvoir faire ce genre de changement sans impact sur les plugins existants.
mes 2 sous.
@++
Bonjour, je prends le fil en route ... et avec beaucoup d'intérêt, aussi vais-je y mettre mes trois sous !!
C'est juste. Cela dit le pb est déjà là: en gros, tous les scripts (essentiellement dans action/) qui ont plusieurs UPDATE dans leur code ont déjà cette faible. Ce serait l'occasion de mettre ça au carré.
Committo,Ergo:Sum
J'ai un peu de mal à saisir l'intérêt d'une table par statut, car
j'ai peur que cela ne revienne à encore figer ce que tu voudrais au
contraire assouplir. En effet, comment faire si j'ai besoin d'ajouter
un statut spécifique à une problématique : créer une nouvelle table
pour ce statut ?
oui.
Si j'ai bien compris la problématique, amha (mais c'est c'est un peu
de mes sous !) je verrai plutôt une table qui recense tous les
statuts, liée aux objets qui en ont besoin par une clé (id_article,
id_auteur ...). On pourrait au contraire imaginer de mettre des
statuts "sur mesure" à tout objet dans spip, auteur, article,
rubrique ...
Une table qui recense tous les status, ça revient à un groupe de mot-clés nommé par exemple "statut".
On pourrait assez facilement créer ce groupe de mots et consulter la table mots_article plutot que le champ statut de la table article comme actuellement. Le pb c'est comment spécifier si un auteur à le droit de donner un certain statut à un certain article. En SPIP et en SQL les droits s'expriment par rapport à une table, pas par rapport à une valeur précise.
Personnellement, je gère selon ce principe, pour mes besoins
professionnels, 53 tables relationnelles (http://www.prociale.com,
voir la partie Démo), les type de risques de contrats d'assurance
(oui, je sais, c'est très spécifique, mais la gestion des données est
la même), les types de risques étant dans une seule table, en nombre
illimité, avec les clés externes qui vont avec ...
Typiquement comment fais-tu pour dire que telle personne ne peut faire telle opération ? C'est un pb classique dans l'informatisation de l'assurance: les employés déclarant les sinistres peuvent y être assurés, mais il faut leur retirer le droit d'enregistrer les sinistres les concernant sinon il peuvent ruiner la baraque.
Committo,Ergo:Sum
Le problème c’est que je suis le premier à vouloir documenter, mais n’étant pas développeurs, je ne comprend que peu de chose sur la structure du noyeau de SPIP et je ne parle pas de ce qui est MySQL. Les commentaires donnent quand même un bon coup de main sur les fichiers PHP.
De plus, avant de documenter, il serait peut-être intéressant de faire une liste de ce qui manque… peut-être faire une liste spip-doc?
Ou les documentalistes pourrons échanger sur ce qui manque, annoncer les ajouts pour que les dev passent dessus et complete/rectifie les erreurs, organiser un tout cohérent, entre eux…
Perso si on me donne un espace pour ça, je suis le premier à poster les" astuces et conseils pratiques" qui sortent tous les jours sur la liste de support. Si on regarde Photoshop (que je connais sur le bout des doigts), c’est comme ça que la plupart des gens apprennent… C.A.D par besoin spécifique… Je suis pas encore super calé en SPIP, j’espère que ça vienne et un jour. Mais si je peux contribuer à hauteur de mes moyens, je vais le faire.
Je lis néanmoins vos messages de dev avec beaucoup d’intérêt afin de me former sur le tas à ce niveau là. Avec le temps, ça viendra.
Bonne journée.
PS: sur la question des champs extra, je trouve ça, pour le moment, encore compliqué et en effet, dure à voir au niveau de l’interface privé. J’ai de la peine à saisir le fonctionnement du plugin form&table… Et c’est vrai qu’il serait absolument fantastique de pouvoir mettre autant de formulaire que l’on veux sur un article voir une rubrique et que la récupération se fasse par une balise (identifié par un numéro par exemple) et tout cela, depuis la partie admin. 
Le problème c'est que je suis le premier à vouloir documenter, mais n'étant pas développeurs, je ne comprend que peu de chose
Perso si on me donne un espace pour ça, je suis le premier à poster les" astuces et conseils pratiques" qui sortent tous les jours sur la liste de support.
Le site de la doc est ouvert à l'inscription:
http://www.spip.net/spip.php?page=login
tu peux t'inscrire et soumettre des articles décrivant tes astuces et tes conseils. Plusieurs articles de la doc ont cette origine, on est toujours preneurs.
sur la question des champs extra, je trouve ça, pour le moment, encore compliqué
Ces champs doivent être considéré comme obsolètes depuis que le compilateur de la 1.8.
Committo,Ergo:Sum