[SPIP Zone] [Spip-zone-commit] r10915 - in /_plugins_/_stable_/forms/forms_et_tables_1_9_1/inc: forms.php forms_type_champs.php

Archives Zone
1

Bonjour,
pour

le DELETE est indispensable car pour un (id_form,id_donnee,champ) on peut avoir plusieurs valeurs. La mise a jour ne peut donc pas faire d'update, ce qui necessite du coup un insert precede d'un delete.
On peut sans doute ameliorer cela du point de vue fiabilite en mettant le delete apres sur un critere de date du champ maj, mais cela demande des tests que je n'ai pas le temps de faire maintenant.
Je corrige donc ton commit.

Sinon, tu as ajoute un parametre id_donnee sur Forms_valide_conformite_champs_reponse_post et Forms_valide_champs_reponse_post dont tu ne te sers pas. Quel etait le but de cela ?
De maniere generale il faut faire attention aux changement de prototypes des fonctions car est de plus en plus utilise par d'autres plugins.
Je suis en train d'essayer de regrouper toute l'api a destination des autres plugins dans base/forms_api, mais cela n'est pas encore tout complet.

Cedric

phil@africacomputing.org a écrit :

Author: phil@africacomputing.org
Date: Tue Apr 3 10:34:43 2007
New Revision: 10915

Log:
Correction bug lors d'une maj d'une donnéee (date de publication d'une donnée réinitialisée à la date de mise à jour) + suppression d'un var_dump oublié lors d'un précédent commit (oups!)

Modified:
    _plugins_/_stable_/forms/forms_et_tables_1_9_1/inc/forms.php
    _plugins_/_stable_/forms/forms_et_tables_1_9_1/inc/forms_type_champs.php

Modified: _plugins_/_stable_/forms/forms_et_tables_1_9_1/inc/forms.php

--- _plugins_/_stable_/forms/forms_et_tables_1_9_1/inc/forms.php (original)
+++ _plugins_/_stable_/forms/forms_et_tables_1_9_1/inc/forms.php Tue Apr 3 10:34:43 2007
@@ -593,7 +593,7 @@
       // D'abord creer la reponse dans la base de donnees
       if ($ok) {
         if ($id_donnee>0 AND autoriser('modifier', 'donnee', $id_donnee, NULL, array('id_form'=>$id_form))){
- spip_query("UPDATE spip_forms_donnees SET date=NOW(), ip="._q($GLOBALS['ip']).", url="._q($url).", confirmation="._q($confirmation).", cookie="._q($cookie)." ".
+ spip_query("UPDATE spip_forms_donnees SET ip="._q($GLOBALS['ip']).", url="._q($url).", confirmation="._q($confirmation).", cookie="._q($cookie)." ".
             "WHERE id_donnee="._q($id_donnee));
           // Pourquoi ce Delete alors qu'il est effectué avant l'insertion des données ? => redondant + risque de perte de données
           //spip_query("DELETE FROM spip_forms_donnees_champs WHERE id_donnee="._q($id_donnee));

Modified: _plugins_/_stable_/forms/forms_et_tables_1_9_1/inc/forms_type_champs.php

--- _plugins_/_stable_/forms/forms_et_tables_1_9_1/inc/forms_type_champs.php (original)
+++ _plugins_/_stable_/forms/forms_et_tables_1_9_1/inc/forms_type_champs.php Tue Apr 3 10:34:43 2007
@@ -146,7 +146,7 @@
             }
           }
         }
- if ($type == 'fichier') {var_dump($_FILES[$champ]); exit;
+ if ($type == 'fichier') {
           if (!$taille = $_FILES[$champ]['size']) {
             $erreur[$champ] = _T("forms:echec_upload");
           }

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit
  

2

Hello !

cedric.morin@yterium.com a écrit :

Bonjour,
pour
Connexion · GitLab
le DELETE est indispensable car pour un (id_form,id_donnee,champ) on peut avoir plusieurs valeurs. La mise a jour ne peut donc pas faire d'update, ce qui necessite du coup un insert precede d'un delete.
On peut sans doute ameliorer cela du point de vue fiabilite en mettant le delete apres sur un critere de date du champ maj, mais cela demande des tests que je n'ai pas le temps de faire maintenant.
Je corrige donc ton commit.

Ok. Merci pour cette précision.

Sinon, tu as ajoute un parametre id_donnee sur Forms_valide_conformite_champs_reponse_post et Forms_valide_champs_reponse_post dont tu ne te sers pas. Quel etait le but de cela ?

Le paramètre id_donnee a été ajouté pour corriger un bug sur les champs de type "fichier à télécharger".

Lorsqu'on souhaite mettre à jour une donnée contenant un champ de ce type, on se heurte au problème suivant : le <input type='file'> reste vide. On obtient donc soit un message d'erreur dans le cas où ce champ est obligatoire soit la suppression du fichier lié dans le cas où le champ n'est pas obligatoire.

La connaissance de l'id_donnee dans Forms_valide_conformite_champs_reponse_post permet de récupérer la valeur du champ dans le cas d'une mise à jour et donc de ne pas obliger à uploader à nouveau un fichier déjà uploadé.
La connaissance de l'id_donnee dans Forms_valide_champs_reponse_post permet de récupérer la valeur déjà existante si un nouveau upload n'est pas effectué et de l'utiliser pour la mise à jour de la donnée.

De maniere generale il faut faire attention aux changement de prototypes des fonctions car est de plus en plus utilise par d'autres plugins.
Je suis en train d'essayer de regrouper toute l'api a destination des autres plugins dans base/forms_api, mais cela n'est pas encore tout complet.

C'est clair que j'ai pas assuré. Mea culpa, j'en prends note : un mail avant ce genre de modif !!! Au pire, j'aurais du mettre ce paramètre en dernier avec valeur par défaut pour ne pas casser avec d'autres plugins.

Je profite de ce courrier pour quelques retours d'expériences sur forms_et_tables. :wink:

J'utilise (et teste) intensivement forms_et_tables dans le cadre d'un site d'échange d'enregistrements audios. Initialement, on pensait adapter nos besoins à la structure d'un article. Avec forms_et_tables, on crée une entité répondant exactement aux besoins exprimés au lieu d'adapter nos besoins aux articles.

Voir http://test.afriradio.net/ecrire/ pour voir l'usage (login/pass .htaccess et auteur = test/test). [Site de test indépendant du site en prod donc test et publications expérimentales possibles].
Les entités utilisées sont : form1 (enregistrement audio), auteurs, groupes de mots et mots-clés. Des modèles contenant des boucles sur les données de form1 sont utilisés pour l'affichage des données sur la partie publique.

Sur test.afriradio.net, par rapport à la version svn de forms_et_tables :

- les listes de mots-clés non obligatoires sont présentés sous la forme de listes déroulantes à choix multiples et non de cases à cocher (pour éviter par des sections trop longues d'une cinquantaine de cases à cocher) => formulaires/forms_select_mot.html spécifique

- au niveau des champs de type "fichier à télécharger", dans le cas où des fichiers sont présents dans tmp/upload/ un select fichier_x_upload est ajouté après chaque input fichier_x pour permettre d'associer des fichiers déjà téléchargés par ftp au lieu de l'upload par http (problématique des fichiers de plusieurs Mo uploadés depuis des connexions lentes et/ou peu stables). Si un fichier est sélectionné dans le select, on remplit $_FILES[$champ] à partir du fichier sélectionné pour le traiter comme s'il avait été uploadé dans /tmp via l'input d'upload du formulaire => inc/forms_type_champs.php inc/forms.php et formulaires/forms_structure.html spécifiques.

Enfin du fait que les articles ne sont guères utilisés, l'interface dite "simplifiée" est réellement simplifiée aux seuls besoins des utilisateurs (l'interface complexe renvoyant vers l'interface habituelle de spip). Ce qui m'amène à préciser qu'il serait intéressant de mettre sous la forme de fonction _dist les fonctions suivantes de spip : init_body, bandeau_double_rangee, definir_barre_boutons et installer_gadgets.

Je commence à m'intéresser à la jointure entre forms. Cédric, j'ai vu la déclaration des champs de jointure dans r10745 mais pas encore la prise en compte de ces champs dans forms_upgrade.php et par la suite... Si je peux me rendre utile...

Amicalement,
Philippe

3

Philippe Drouot a écrit :

Hello !

cedric.morin@yterium.com a écrit :

Bonjour,
pour
Connexion · GitLab
le DELETE est indispensable car pour un (id_form,id_donnee,champ) on peut avoir plusieurs valeurs. La mise a jour ne peut donc pas faire d'update, ce qui necessite du coup un insert precede d'un delete.
On peut sans doute ameliorer cela du point de vue fiabilite en mettant le delete apres sur un critere de date du champ maj, mais cela demande des tests que je n'ai pas le temps de faire maintenant.
Je corrige donc ton commit.

Ok. Merci pour cette précision.

Sinon, tu as ajoute un parametre id_donnee sur Forms_valide_conformite_champs_reponse_post et Forms_valide_champs_reponse_post dont tu ne te sers pas. Quel etait le but de cela ?

Le paramètre id_donnee a été ajouté pour corriger un bug sur les champs de type "fichier à télécharger".

Lorsqu'on souhaite mettre à jour une donnée contenant un champ de ce type, on se heurte au problème suivant : le <input type='file'> reste vide. On obtient donc soit un message d'erreur dans le cas où ce champ est obligatoire soit la suppression du fichier lié dans le cas où le champ n'est pas obligatoire.

La connaissance de l'id_donnee dans Forms_valide_conformite_champs_reponse_post permet de récupérer la valeur du champ dans le cas d'une mise à jour et donc de ne pas obliger à uploader à nouveau un fichier déjà uploadé.
La connaissance de l'id_donnee dans Forms_valide_champs_reponse_post permet de récupérer la valeur déjà existante si un nouveau upload n'est pas effectué et de l'utiliser pour la mise à jour de la donnée.

De maniere generale il faut faire attention aux changement de prototypes des fonctions car est de plus en plus utilise par d'autres plugins.
Je suis en train d'essayer de regrouper toute l'api a destination des autres plugins dans base/forms_api, mais cela n'est pas encore tout complet.

C'est clair que j'ai pas assuré. Mea culpa, j'en prends note : un mail avant ce genre de modif !!!

non non faut pas alourdir. On va pas se remplir des formulaires en ligne de demande d'autorisation de commit quand meme !

Au pire, j'aurais du mettre ce paramètre en dernier avec valeur par défaut pour ne pas casser avec d'autres plugins.

oui voila c'est moins risqué. Pas de bobo ce coup ci je crois.

Je profite de ce courrier pour quelques retours d'expériences sur forms_et_tables. :wink:

J'utilise (et teste) intensivement forms_et_tables dans le cadre d'un site d'échange d'enregistrements audios. Initialement, on pensait adapter nos besoins à la structure d'un article. Avec forms_et_tables, on crée une entité répondant exactement aux besoins exprimés au lieu d'adapter nos besoins aux articles.

oui c'est exactement pour ca que j'ai développé la partie tables :slight_smile:

Voir http://test.afriradio.net/ecrire/ pour voir l'usage (login/pass .htaccess et auteur = test/test). [Site de test indépendant du site en prod donc test et publications expérimentales possibles].
Les entités utilisées sont : form1 (enregistrement audio), auteurs, groupes de mots et mots-clés. Des modèles contenant des boucles sur les données de form1 sont utilisés pour l'affichage des données sur la partie publique.

Sur test.afriradio.net, par rapport à la version svn de forms_et_tables :

- les listes de mots-clés non obligatoires sont présentés sous la forme de listes déroulantes à choix multiples et non de cases à cocher (pour éviter par des sections trop longues d'une cinquantaine de cases à cocher) => formulaires/forms_select_mot.html spécifique

- au niveau des champs de type "fichier à télécharger", dans le cas où des fichiers sont présents dans tmp/upload/ un select fichier_x_upload est ajouté après chaque input fichier_x pour permettre d'associer des fichiers déjà téléchargés par ftp au lieu de l'upload par http (problématique des fichiers de plusieurs Mo uploadés depuis des connexions lentes et/ou peu stables). Si un fichier est sélectionné dans le select, on remplit $_FILES[$champ] à partir du fichier sélectionné pour le traiter comme s'il avait été uploadé dans /tmp via l'input d'upload du formulaire => inc/forms_type_champs.php inc/forms.php et formulaires/forms_structure.html spécifiques.

Enfin du fait que les articles ne sont guères utilisés, l'interface dite "simplifiée" est réellement simplifiée aux seuls besoins des utilisateurs (l'interface complexe renvoyant vers l'interface habituelle de spip). Ce qui m'amène à préciser qu'il serait intéressant de mettre sous la forme de fonction _dist les fonctions suivantes de spip : init_body, bandeau_double_rangee, definir_barre_boutons et installer_gadgets.

Je commence à m'intéresser à la jointure entre forms. Cédric, j'ai vu la déclaration des champs de jointure dans r10745 mais pas encore la prise en compte de ces champs dans forms_upgrade.php et par la suite... Si je peux me rendre utile...

Amicalement,
Philippe