Cedric a écrit :
Joseph a écrit :
Le plugin forms et tables peut permettre un travail collaboratif, par exemple dans le cadre d'un intranet associatif, sur la gestion d'une table de données. Cependant, quelques options supplémentaires seraient les bienvenues. Je les présente dans la suite de ce mail et je veux bien les coder. Cependant, certaines impliquent quelques petites modifications de la table spip_forms. Il n'y a pas de règles spécifiques de commit indiquées pour ce plugin. Je soumets donc ces propositions ici avant, éventuellement de les coder. Si vous pensez que certaines ne devraient pas être intégrées au plugin ou qu'elles nécessitent une discussion préalable, merci de réagir sur la liste.
Les propositions sont les suivantes :
- Dans la définition des propriétés d'une table, sous l'item "Données modifiables dans l'espace public", ajout d'une option "Données modifiables par tous".
- Ajout d'un item "Données supprimables depuis l'espace public" avec trois items : Non / Oui par l'utilisateur / Oui par tous. Dans le modèle table, ajout d'une croix dans le tableau généré lorsque l'utilisateur a le droit de supprimer une saisie. Si clic sur la croix, message de confirmation avant suppression.
bon deja la config des formulaires et table tient du cokpit de boeing.
En rajouter sans refondre l'ergonomie n'est pas la voie idéale.
Pour moi ce genre de besoin ponctuel et spécifique tient plus de la personalisation de la fonction autoriser_xx qui va bien et/ou de la surcharge des squelettes de bases
Le problème c'est que toutes les tables ne doivent pas forcément être modifiables par tous. Donc il faut pouvoir préciser la situation pour chaque table séparément. Si modif dans forms et tables, c'est une modif légère. S'il faut programmer ses propres fonctiosn d'autorisation, c'ets lours à gérer et comment font ceux qui ne sont pas programmeurs.
- Si réponses multiples, dans le modele form, ajout d'un lien "Nouvelle saisie" sous le message "Votre saisie a été enregistrée" qui apparait après validation d'une saisie.
bof ?
Pour un utilisateur lambda, c'est pas évident qu'il faut réouvrir la page pour pouvoir effectuer une nouvelle saisie (cf. retour d'expérience, "ah bon ? pourquoi ?). C'est juste une amélioration mineure coté programmation mais ca simplifie beaucoup la compréhension pour quelqu'un qui vient visiter le site.
- Si réponses multiples, dans le modele form, ajout du texte "Nouvelle saisie" au début du formulaire en l'absence d'id_donnee dans l'URL et du texte "Modifier la saisie n°id_donnee" lorsqu'un id_donnee est passé dans l'URL.
de l'ordre de la personalisation aussi ?
Pas uniquement, car il s'agit pour un utilisateur lambda de bien comprendre ce qu'il est en train de faire. Créer une fiche ou la modifier. il ne faut pas oublier que pour une majorité de site, les utilisateurs de SPIP utiliseront les modèles fournis par défaut.
- Dans le modele form, quand un id_donnee est passé dans l'URL, le formulaire est pré chargé et permet de modifier une saisie. Ajout d'un bouton ANNULER à côté du bouton VALIDER.
oui, mais qui renvoie vers quoi ?
Tout simplement sur #SELF en retirant le paramètre id_donnee. on revient à un formulaire vierge pour une nouvelle saisie/
- Dans le modele form, quand un id_donnee est passé dans l'URL et que l'individu n'a pas le droit de modifier cette fiche, le formulaire n'est pas préchargé. Cependant, s'il est rempli, alors la fiche est modifiée (BUG).
ah il faut corriger
Je propose que si un id_donnee est passé dans l'URL et que l'individu n'a pas les droits pour modifier cette saisie, alors le formulaire n'est pas affiché, un message indique que l'individu n'a pas les droits pour modifier cette fiche. Si "réponses multiples", un lien vers une nouvelle saisie est proposé.
oui
ok
- Ajout dans les propriétés d'une table d'une option "Données téléchargeables depuis l'espace public" avec trois options : Non / Oui sans mot de passe / Oui avec mot de passe. Si mot de passe, champs texte pour le définir. Dès lors, il est possible de télécharger la table au format excel à l'aide d'une URL du type spip.php?action=forms_telecharger&arg=1&delim=TAB&var_mode=download
(sans mot de passe) ou spip.php?action=forms_telecharger&arg=1&delim=TAB&var_mode=download&mdp=1234567890
(avec mot de passe).
c'est de l'ordre du squelette personalisé, ca, non ?
Non. Pourquoi refaire un squelette personnalisé alors que forms_et_table fournit déjà le script pour télécharger au formats csv ou tab ? Le seul point concerne les vérifications de droits faites par forms_et_table pour télécharger au format excel. De plus, ca permet à un script externe (sur un autre site par exemple) de récupérer la table de données.
par ailleurs, si dans action/forms_telecharger.php il y a une vérification sur autorisation de télécharger un form, dans inc/form_export.php la vérification porte sur les droits d'administrer un form. Enfin, même point que précedemment, il faut pouvoir donner des droits différents pour différentes tables.
- Ajout d'un modele "telecharger_table" permettant de produire un formulaire de téléchargement de la table spécifiée si l'option est activée dans les propriétés de la table. Si un mot de passe est requis, celui-ci devra être passé manuellement lors de l'appel du modèle dans un article.
si on veut
Ca découle du point précédent. Si on permet le téléchargement.
Qu'en pensez-vous ?
Actuellement le plugin est menifestement trop complexe à utiliser et son ergonomie est déroutante.
C'est aussi du à un manque de documentation sur les différentes propriétés des formulaires. Du coup on doit les deviner ou aller farfouiller le code pour comprendre exactement comment ca fonctionne. Par exemple, il m'a fallu deux jours avant de comprendre que l'option 'modifiables par l'utilisateur dans l'espace public' ne permettait en réalité que de modifier les fiches que l'on a soi-même crée.
Ma feuille de route, pour la version 2008 sera donc :
- le nettoyage du code avec l'abandon de la compat 191 (voire 192)
- la refonte de l'ergonomie du bazar
- la simplification de la configuration des formulaires et des tables
- la restructuration semantique html des formulaire générés
et si possible de la doc...
Je ne suis pas sur que chercher à couvrir tous les cas en clicodrome soit la meilleure option.
Je préfère que les options que tu évoques soient par exemple gérées par un plugin de f&t dédié tables collaboratives, a moins que ca ne soit clairement un besoin récurrent identifié et réclamé par beaucoup ?
Pour créer un plugin sur forms et tables, cela signifie mettre en place des pipelines en différents endroits de forms et tables pour ne pas avoir à tout surcharger (exemple le rajout d'un troisième choix à données modifiables dans l'espace public). Ou stocker alors les informations de propriétés (une nouvelle table ou modifier la table spip_forms existantes). Comment assurer facilement le suivi avec les multiples évolutions de forms_et_tables si plusieurs des fonctiosn doivent être surchargées, etc.
Par ailleurs, notamment avec Crayon, SPIP permet aujourd'hui de pouvoir réaliser un maximum de choses depuis l'espace public. Autrement dit, SPIP est de plus en plus envisagé comme outil de travail collaboratif à la place d'un Wiki. D'ailleurs, aucun Wiki ne permet aujourd'hui de gérer collectivement une table de données.
forms_et_tables est un plugin généraliste devant permettre de pouvoir répondre à un grand nombre de situations. enfin le travail collaboratif reste un des fondements de SPIP (cf. P de Partagé). Pourquoi s'en priver ?