[SPIP Zone] forms&tables

Archives Zone
1

Hello,
je fais des tests en 1.9.2 du plugin, et j'ai des soucis de cache avec les formulaires modifiables : les valeurs de A s'affichent pour B.
En fait, ca parait normal, puisque les modeles sont calculés en meme temps que la balise.
Ce que je ne comprend pas en fait, c'est qu'en 1.9.1, je n'avais pas ce probleme...

Bref, ma strategie de réaffichage des données dans le formulaire est mauvaise ou en tous cas, elle necessite un cache à 0 (ou cache par session) la ou la balise est calculée.
En fait, il faudrait générer le formulaire vide et le remplir avec un script qui lui doit utilisé un cache dépendant de l'id_auteur ou du cookie.
J'ai fait ca sur un autre projet pour limiter les caches "personnels" et si j'ai bien compris, crayons fait ca aussi.
Je vais creuser un peu de ce coté mais les idées sont les bienvenues.

Pour simplifier le traitement, il me faudrait un id et une classe au niveau du formulaire :
dans formulaires/forms.html :
- <form method='post' action='#ENV{self}#form#ID_FORM'
+ <form id='forms_form#ID_FORM' class='forms_form' method='post' action='#ENV{self}#form#ID_FORM'

---------------------

C'est très utile aussi pour faire une validation javascript...
A ce propos, j'ai eu un autre souci : j'ai voulu faire des champs numeriques obligatoires et ca coince avec le 0.

Je ne sais pas si on peut contourner ce probleme coté serveur, mais 0 est considéré comme vide.

En attendant, j'ai créé un nouveau type d'input et je remplace les 0 par un espace au submit.

---------------------

Dans les ameliorations en reflexion, comme je l'avais indiqué, je voudrais séparer en 3 flags la notion de sondage :
- gestion du cookie
- confirmation par mail
- gestion des stats

Comme la gestion des propriétés est déjà bien (trop?) complexe, j'avais imaginé gérer des "profils de formulaire".
L'idée, c'est de mettre dans l'onglet propriété actuel le formulaire complet des parametres (qui deviendrait propriétés avancées), mais, d'en masquer une partie (qui resterait quand meme accessible avec un bouton propriétés avancées) en permettant à l'utilisateur de choisir des "profils".
on pourrait avoir par exemple :
- Sondage public :
    - cookie : oui
    - confirmation par mail : oui
    - gestion des stats : oui
    - modifiable : non
    - unique : oui
    - articles : non
    - documents : non
- profil utilisateur :
    - cookie : oui
    - confirmation par mail : non
    - gestion des stats : non
    - modifiable : oui
    - unique : oui
    - articles : non
    - documents : non
   ...

En fait, avec un peitit tableau de parametrage, on pourrait personnaliser ca facilement en fonction des usages.
Techniquement, je pensais juste rajouter une liste de profil qui agirait directement sur les valeurs du formulaire de propriétés avancées.

Qu'en dites vous ?

@++

2

spipcarto a écrit :

Hello,
je fais des tests en 1.9.2 du plugin, et j'ai des soucis de cache avec les formulaires modifiables : les valeurs de A s'affichent pour B.
En fait, ca parait normal, puisque les modeles sont calculés en meme temps que la balise.
Ce que je ne comprend pas en fait, c'est qu'en 1.9.1, je n'avais pas ce probleme...
  

hum c'est un peu chaud ca... et en 191 ca devait etre pareil, mais masqué par un autre effet j'imagine.
Il y a le meme type de probleme avec le formulaire sondage qui affiche soit le resultat soit le formulaire selon qu'on a repondu ou non.
Pour m'en tirer j'avais mis un hack qui modifie le marqueur de cache (donc le cache utilisé) selon qu'on a repondu ou non au sondage.
La difficulté est qu'il faut pas invalider tout le cache mais uniquement LA page ou apparait le formulaire en question, que l'on doit decider du cache
avant tout calcul de page.
J'utilise pour cela le lien id_article-id_form, et si l'on est donc dans un contexte ou id_article est connu et lié a id_form auquel on a repondu, je met le marqueur de cache.
Je faisais cela car le formulaire etait inséré par une fonction post propre dans le #TEXTE, donc stocké dans le cache de l'article (evidemment ca ne marchait plus si le formulaire etait dans une rubrique, un mot ou autre)
En ecrivant cela, je pense que l'on pourrait peut etre améliorer et se baser aussi directement sur id_form connu, car le formulaire est issu d'un modele, donc stocké sans doute dans ce cache.
Cette stratégie est je pense generalisable a ton probleme aussi.

Bref, ma strategie de réaffichage des données dans le formulaire est mauvaise ou en tous cas, elle necessite un cache à 0 (ou cache par session) la ou la balise est calculée.
En fait, il faudrait générer le formulaire vide et le remplir avec un script qui lui doit utilisé un cache dépendant de l'id_auteur ou du cookie.
J'ai fait ca sur un autre projet pour limiter les caches "personnels" et si j'ai bien compris, crayons fait ca aussi.
Je vais creuser un peu de ce coté mais les idées sont les bienvenues.

Pour simplifier le traitement, il me faudrait un id et une classe au niveau du formulaire :
dans formulaires/forms.html :
- <form method='post' action='#ENV{self}#form#ID_FORM'
+ <form id='forms_form#ID_FORM' class='forms_form' method='post' action='#ENV{self}#form#ID_FORM'
  

pas de probleme pour ajouter un id a cet endroit il me semble

---------------------

C'est très utile aussi pour faire une validation javascript...
A ce propos, j'ai eu un autre souci : j'ai voulu faire des champs numeriques obligatoires et ca coince avec le 0.

Je ne sais pas si on peut contourner ce probleme coté serveur, mais 0 est considéré comme vide.
  

ah un test mal ecrit surement !

En attendant, j'ai créé un nouveau type d'input et je remplace les 0 par un espace au submit.

---------------------

Dans les ameliorations en reflexion, comme je l'avais indiqué, je voudrais séparer en 3 flags la notion de sondage :
- gestion du cookie
- confirmation par mail
- gestion des stats

Comme la gestion des propriétés est déjà bien (trop?) complexe, j'avais imaginé gérer des "profils de formulaire".
L'idée, c'est de mettre dans l'onglet propriété actuel le formulaire complet des parametres (qui deviendrait propriétés avancées), mais, d'en masquer une partie (qui resterait quand meme accessible avec un bouton propriétés avancées) en permettant à l'utilisateur de choisir des "profils".
on pourrait avoir par exemple :
- Sondage public :
    - cookie : oui
    - confirmation par mail : oui
    - gestion des stats : oui
    - modifiable : non
    - unique : oui
    - articles : non
    - documents : non
- profil utilisateur :
    - cookie : oui
    - confirmation par mail : non
    - gestion des stats : non
    - modifiable : oui
    - unique : oui
    - articles : non
    - documents : non
   ...

En fait, avec un peitit tableau de parametrage, on pourrait personnaliser ca facilement en fonction des usages.
Techniquement, je pensais juste rajouter une liste de profil qui agirait directement sur les valeurs du formulaire de propriétés avancées.

Qu'en dites vous ?
  

sur le principe ca me parait bien mais la confirmation par mail n'est pas du oui ou non, il faut indiquer une adresse mail
disons que cet aspect interface, meme si il a son importance, arrive apres la consolidation des fonctionnalités et le debugage a mon avis, et je prefere qu'on murisse ca avant de rechanger.

Cedric

3

cedric.morin@yterium.com a écrit :

spipcarto a écrit :

Hello,
je fais des tests en 1.9.2 du plugin, et j'ai des soucis de cache avec les formulaires modifiables : les valeurs de A s'affichent pour B.
En fait, ca parait normal, puisque les modeles sont calculés en meme temps que la balise.
Ce que je ne comprend pas en fait, c'est qu'en 1.9.1, je n'avais pas ce probleme...
  

hum c'est un peu chaud ca... et en 191 ca devait etre pareil, mais masqué par un autre effet j'imagine.

Sans doute, mais c'est bizarre, j'ai fait pas mal de tests et c'est utilisé actuellement sur un site, personne ne m'a fait remonter de croisement de données, dans le doute, j'ai quand meme mis le cache à 0 la ou le formulaire s'affiche.
Mais j'ai l'impression qu'il y a quand meme une difference entre la 1.9.1 et la 1.9.2 sur l'execution des balises dynamiques.

Il y a le meme type de probleme avec le formulaire sondage qui affiche soit le resultat soit le formulaire selon qu'on a repondu ou non.
Pour m'en tirer j'avais mis un hack qui modifie le marqueur de cache (donc le cache utilisé) selon qu'on a repondu ou non au sondage.
La difficulté est qu'il faut pas invalider tout le cache mais uniquement LA page ou apparait le formulaire en question, que l'on doit decider du cache
avant tout calcul de page.
J'utilise pour cela le lien id_article-id_form, et si l'on est donc dans un contexte ou id_article est connu et lié a id_form auquel on a repondu, je met le marqueur de cache.
Je faisais cela car le formulaire etait inséré par une fonction post propre dans le #TEXTE, donc stocké dans le cache de l'article (evidemment ca ne marchait plus si le formulaire etait dans une rubrique, un mot ou autre)
En ecrivant cela, je pense que l'on pourrait peut etre améliorer et se baser aussi directement sur id_form connu, car le formulaire est issu d'un modele, donc stocké sans doute dans ce cache.
Cette stratégie est je pense generalisable a ton probleme aussi.

heu pas sur que ca regle le probleme : tu auras beau invalider le cache du modele, si j'ai bien compris, le TEXTE mis en cache de l'article contient le resultat au moment du calcul, non ?
En fait, tant qu'il n'y a pas de POST, la balise dynamique ne semble pas executée, alors qu'il me semble que c'etait le cas avant.

Mais bon, c'est pas tres grave, ca me parait plus logique de faire un javascript inséré dans INSERT_HEAD avec un cache perso pour réalimenter le formulaire en cas de modif.

Je vais quand meme essayer de comprendre le fonctionnement de ton marqueur mais j'ai pas tout capté encore...

sur le principe ca me parait bien mais la confirmation par mail n'est pas du oui ou non, il faut indiquer une adresse mail

Ah, en fait, je pensais à la validation de la reponse, pas à la selection du champ qui contient le mail
Mais j'ai survolé le code de ce coté, je dis peut etre des betises

disons que cet aspect interface, meme si il a son importance, arrive apres la consolidation des fonctionnalités et le debugage a mon avis, et je prefere qu'on murisse ca avant de rechanger.

OK, de toutes facons, je pensais juste à une "surcouche" en javascript, je ne pensais pas toucher à la page elle meme.

Mais effectivement, le plus urgent, c'est de stabiliser.

Ce qui me gene le plus, c'est ce parametre sondage qui sert à 2 choses.
Il sert à la fois à :
- affichage ou non des resultats/cumuls
- gerer ou non une confirmation de la reponse (lien dans le mail avec un hash je presume)

c'est ces 2 fonctionnalités que je voudrais séparer pour pouvoir gérer des utilisateurs non authentifiés, en passant par des confirmations par mail+cookie ou pour gérer des cumuls sur autre chose que des "sondages" (formulaires à reponses multiple par exemple)

voila, sinon ca a l'air de tourner plutot bien.

@++

4

Ce qui me gene le plus, c'est ce parametre sondage qui sert à 2 choses.
Il sert à la fois à :
- affichage ou non des resultats/cumuls
- gerer ou non une confirmation de la reponse (lien dans le mail avec un hash je presume)
  

ah non non aucun rapport
le parametre sondage sert juste a valider des reponses uniques sur la base d'un cookie, et a empecher donc une seconde reponse d'un meme internaute.
Il affiche ou non les resultats en fonction du caractére publique.

La confirmation par mail ne s'entend dans le sens 'le site envoie un mail a l'internaute pour confirmer qu'il a bien enregistré la saisie', c'est plus un accusé de reception en fait.
Ca serait sans doute plus clair comme terme d'ailleurs

c'est ces 2 fonctionnalités que je voudrais séparer pour pouvoir gérer des utilisateurs non authentifiés, en passant par des confirmations par mail+cookie ou pour gérer des cumuls sur autre chose que des "sondages" (formulaires à reponses multiple par exemple)

voila, sinon ca a l'air de tourner plutot bien.

@++

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

5

cedric.morin@yterium.com a écrit :

Ce qui me gene le plus, c'est ce parametre sondage qui sert à 2 choses.
Il sert à la fois à :
- affichage ou non des resultats/cumuls
- gerer ou non une confirmation de la reponse (lien dans le mail avec un hash je presume)
  

ah non non aucun rapport
le parametre sondage sert juste a valider des reponses uniques sur la base d'un cookie, et a empecher donc une seconde reponse d'un meme internaute.
Il affiche ou non les resultats en fonction du caractére publique.

ah, OK, donc ca fait doublon avec unique/multiple en fait, non ?