[spip-dev] Gestion des formulaires, état des lieux ?

azerttyu · Mai 20, 2008, 7:35

S'lt

Je suis en train de jouer avec les formulaire et je constate que nous
avons diverses manières de gérer les formulaires.
Le problème c'est que je n'ai pas trouvé de doc globale.

Si je ne m'abuse nous avons au moins 3 gestions :
- formulaires statique
- formulaire dynamique
- formulaire CVT

Pour être franc, je suis largué concernant les formulaires statiques.
Je crois que c'est une variante des formulaires dynamique. Mais je ne
sais pas où ça varie.

Pour les formulaires dynamiques, je crois que nous avons :
- une page qui appelle un #FORMULAIRE_MONFORMULAIRE{arg}
- un squelette dans formulaires/monformulaire.html
-- <form id="monformulaire" method="post"
action="#ENV{self}#formulaire_monformulaire">
-- [(#ENV*{message}?{'',' '}) pour les erreurs ?
-- (#ENV*{commentaire}) pour ?

- un script de traitement dans balises/formulaire_monformulaire.php
-- exploite calculer_balise_dynamique()
-- déclare :
---- balise_FORMULAIRE_MONFORMULAIRE()
---- balise_FORMULAIRE_MONFORMULAIRE_stat()
---- balise_FORMULAIRE_MONFORMULAIRE_dyn()

Pour les formulaire CVT, il y a un début de doc sur spip.net
Nous avons :
- une page qui appelle #FORMULAIRE_MONFORMULAIRE
- un squelette dans formulaires/monformulaire.html
-- exploite
--- #ENV*{editable} pour ?
--- #ACTION_FORMULAIRE{#SELF} pour ?
--- #ENV**{erreurs} pour retourner un message d'erreur global
--- #ENV**{erreurs}|table_valeur{nom} pour extraire un message
d'erreur spécifique

- un répertoire dans formulaires/monformulaire/ contenant
-- charger.php
--- precharge l'ensemble des #ENV
-- verifier.php
--- remplit #ENV**{erreurs}
-- traiter.php

Autre point concernant le formalisme des formulaire. Sommes nous
d'accord pour migrer l'ensemble des formulaire à la sauce formfx c'est
à dire :
- http://romy.tetue.net/spip.php?article523
- http://www.alistapart.com/articles/prettyaccessibleforms

cerdic · Mai 20, 2008, 8:29

S'lt

Je suis en train de jouer avec les formulaire et je constate que nous
avons diverses manières de gérer les formulaires.
Le problème c'est que je n'ai pas trouvé de doc globale.

Si je ne m'abuse nous avons au moins 3 gestions :
- formulaires statique

non, il ya des balises statiques (comme #CHARSET, #URL_ARTICLE ...) qui sont transposées lors de la compilation, mais ne permette justement pas de faire des formulaires

- formulaire dynamique

je préfererai dires des balises dynamiques (comme #LOGIN, #FORMULAIRE_ADMIN, #FORMULAIRE_FORUM ...) qui servent en général à réaliser des formulaires, car le contenu peut changer à chaque hit, et une partie de php est executee à chaque chargement de la page (d'où le nom 'dynamique').
Le mode d'implémentation des balises dynamiques est assez ardu, et dans la pratique, peu de monde développe des formulaires avec à cause de la complexité à laquelle il faut faire face.

- formulaire CVT

Charger/Verifier/Traiter est une surcouche des balises dynamiques qui facilite l'écriture et le dev de formulaires, en séparant bien le code propre à chaque étape, et son moment d'execution.
CVT a vocation a rendre rapide et facile l'implémentation de formulaires dans une application web.

Pour être franc, je suis largué concernant les formulaires statiques.
Je crois que c'est une variante des formulaires dynamique. Mais je ne
sais pas où ça varie.

ca ne sont pas des formulaires, mais des balises #TRUC

Pour les formulaires dynamiques, je crois que nous avons :
- une page qui appelle un #FORMULAIRE_MONFORMULAIRE{arg}
- un squelette dans formulaires/monformulaire.html
-- <form id="monformulaire" method="post"
action="#ENV{self}#formulaire_monformulaire">
-- [(#ENV*{message}?{'',' '}) pour les erreurs ?
-- (#ENV*{commentaire}) pour ?

non, il n'y a aucune convention, chaque balise utilise les siennes.

- un script de traitement dans balises/formulaire_monformulaire.php
-- exploite calculer_balise_dynamique()
-- déclare :
---- balise_FORMULAIRE_MONFORMULAIRE()
---- balise_FORMULAIRE_MONFORMULAIRE_stat()
---- balise_FORMULAIRE_MONFORMULAIRE_dyn()

oui, les deux premieres sont utilisées lors de la compilation, la troisieme est executée à chaque chargement de la balise.
Dans le cas des formulaires implémentés sur ce mode, tout le code est dans cette fonction, aussi bien pour le chargement, la verification, et le traitement.
Le corrolaire est que le traitement du formulaire n'est réalisés qu'à l'affichage de ce formulaire, rendant impossible une redirection apres traitement.
Les formulaires de forum qui nécessitaient cette redirection bénéficiaient d'un traitement exceptionnel en dur dans le core, rendant cela encore plus confus.

Pour les formulaire CVT, il y a un début de doc sur spip.net

que je vais compléter d'ici la sortie pour traiter tous les cas

Nous avons :
- une page qui appelle #FORMULAIRE_MONFORMULAIRE
- un squelette dans formulaires/monformulaire.html
-- exploite
--- #ENV*{editable} pour ?
--- #ACTION_FORMULAIRE{#SELF} pour ?
--- #ENV**{erreurs} pour retourner un message d'erreur global
--- #ENV**{erreurs}|table_valeur{nom} pour extraire un message
d'erreur spécifique

- un répertoire dans formulaires/monformulaire/ contenant
-- charger.php
--- precharge l'ensemble des #ENV
-- verifier.php
--- remplit #ENV**{erreurs}
-- traiter.php

Autre point concernant le formalisme des formulaire. Sommes nous
d'accord pour migrer l'ensemble des formulaire à la sauce formfx c'est
à dire :
- http://romy.tetue.net/spip.php?article523
- Prettier Accessible Forms – A List Apart

trois fois OUI car c'est d'expérience le meilleur modele pour faire varier l'habilage sans forker le html source,
mais il vaut peut etre mieux rester au plus proche de cmxforms en gardant le nom notamment qui permet de retrouver les references biblio
Cédric

Pierre_FICHES · Mai 20, 2008, 8:33

S'lt

Je suis en train de jouer avec les formulaire et je constate que nous
avons diverses manières de gérer les formulaires.
Le problème c'est que je n'ai pas trouvé de doc globale.

Si je ne m'abuse nous avons au moins 3 gestions :
- formulaires statique
- formulaire dynamique
- formulaire CVT

Pour être franc, je suis largué concernant les formulaires statiques.
Je crois que c'est une variante des formulaires dynamique. Mais je ne
sais pas où ça varie.

Pour les formulaires dynamiques, je crois que nous avons :
- une page qui appelle un #FORMULAIRE_MONFORMULAIRE{arg}
- un squelette dans formulaires/monformulaire.html
-- <form id="monformulaire" method="post"
action="#ENV{self}#formulaire_monformulaire">
-- [(#ENV*{message}?{'',' '}) pour les erreurs ?
-- (#ENV*{commentaire}) pour ?

- un script de traitement dans balises/formulaire_monformulaire.php
-- exploite calculer_balise_dynamique()
-- déclare :
---- balise_FORMULAIRE_MONFORMULAIRE()
---- balise_FORMULAIRE_MONFORMULAIRE_stat()
---- balise_FORMULAIRE_MONFORMULAIRE_dyn()

Pour les formulaire CVT, il y a un début de doc sur spip.net
Nous avons :
- une page qui appelle #FORMULAIRE_MONFORMULAIRE
- un squelette dans formulaires/monformulaire.html
-- exploite
--- #ENV*{editable} pour ?
--- #ACTION_FORMULAIRE{#SELF} pour ?
--- #ENV**{erreurs} pour retourner un message d'erreur global
--- #ENV**{erreurs}|table_valeur{nom} pour extraire un message
d'erreur spécifique

- un répertoire dans formulaires/monformulaire/ contenant
-- charger.php
--- precharge l'ensemble des #ENV
-- verifier.php
--- remplit #ENV**{erreurs}
-- traiter.php

Il me semble que Cédric a concaténé les trois parties en un seul fichier (11588)

Autre point concernant le formalisme des formulaire. Sommes nous
d'accord pour migrer l'ensemble des formulaire à la sauce formfx c'est
à dire :
- http://romy.tetue.net/spip.php?article523
- Prettier Accessible Forms – A List Apart

ça semble cohérent non ?

pierre

azerttyu · Mai 20, 2008, 8:52

S'lt

Charger/Verifier/Traiter est une surcouche des balises dynamiques qui
facilite l'écriture et le dev de formulaires, en séparant bien le code
propre à chaque étape, et son moment d'execution.

Tu dis "surcouche" , ça signifie que le _dyn, _stat, demeurent ?
Mais si j'ai bien suivi ça fait le même boulot, juste différemment, non ?

> Pour les formulaire CVT [...] Nous avons :
> -- charger.php
> -- verifier.php
> -- traiter.php

Il me semble que Cédric a concaténé les trois parties en un seul
fichier (11588)

Bien joué C'est mieux avec un seul fichier
Bien que je trouve genant d'avoir dans le même répertoire squelette
(html) et code (php)

> Autre point concernant le formalisme des formulaire. Sommes nous
> d'accord pour migrer l'ensemble des formulaire à la sauce formfx
> - http://romy.tetue.net/spip.php?article523
> - Prettier Accessible Forms – A List Apart

ça semble cohérent non ?

Ouais
Mais ça demande un gros boulot, les skel ne sont pas d'aplomb à ce niveau.
Et si on doit péter aussi un peu de mise en page c'est le moment je crois.

il vaut peut etre mieux rester au plus proche de cmxforms en gardant le
nom notamment qui permet de retrouver les references biblio

cmxforms j'ai du le zappé un truc. J'ai du en entendre parler au
troglo en croyant qu'on parlait formfx

cerdic · Mai 20, 2008, 8:54

S'lt

Je suis en train de jouer avec les formulaire et je constate que nous
avons diverses manières de gérer les formulaires.
Le problème c'est que je n'ai pas trouvé de doc globale.

Si je ne m'abuse nous avons au moins 3 gestions :
- formulaires statique
- formulaire dynamique
- formulaire CVT

Pour être franc, je suis largué concernant les formulaires statiques.
Je crois que c'est une variante des formulaires dynamique. Mais je ne
sais pas où ça varie.

Pour les formulaires dynamiques, je crois que nous avons :
- une page qui appelle un #FORMULAIRE_MONFORMULAIRE{arg}
- un squelette dans formulaires/monformulaire.html
-- <form id="monformulaire" method="post"
action="#ENV{self}#formulaire_monformulaire">
-- [(#ENV*{message}?{'',' '}) pour les erreurs ?
-- (#ENV*{commentaire}) pour ?

- un script de traitement dans balises/formulaire_monformulaire.php
-- exploite calculer_balise_dynamique()
-- déclare :
---- balise_FORMULAIRE_MONFORMULAIRE()
---- balise_FORMULAIRE_MONFORMULAIRE_stat()
---- balise_FORMULAIRE_MONFORMULAIRE_dyn()

Pour les formulaire CVT, il y a un début de doc sur spip.net
Nous avons :
- une page qui appelle #FORMULAIRE_MONFORMULAIRE
- un squelette dans formulaires/monformulaire.html
-- exploite
--- #ENV*{editable} pour ?
--- #ACTION_FORMULAIRE{#SELF} pour ?
--- #ENV**{erreurs} pour retourner un message d'erreur global
--- #ENV**{erreurs}|table_valeur{nom} pour extraire un message
d'erreur spécifique

- un répertoire dans formulaires/monformulaire/ contenant
-- charger.php
--- precharge l'ensemble des #ENV
-- verifier.php
--- remplit #ENV**{erreurs}
-- traiter.php

Il me semble que Cédric a concaténé les trois parties en un seul
fichier (11588)

c'est juste une possibilité, les deux fonctionnent

cerdic · Mai 20, 2008, 9:00

S'lt

Charger/Verifier/Traiter est une surcouche des balises dynamiques qui
facilite l'écriture et le dev de formulaires, en séparant bien le code
propre à chaque étape, et son moment d'execution.

Tu dis "surcouche" , ça signifie que le _dyn, _stat, demeurent ?

techniquement oui, mais si tu implémente en CVT, ce sont des _dyn et _stat génériques qui sont pris, ce qui enleve la nécessité de les ecrire. Cette possibilité existe toujours :
- pour la compatibilité
- pour collecter automatiquement des variables (cf par exemple les forums), la fonction générique par défaut ne transmettant à charger et consors que les arguments passés explicitement à la balise.
C'est donc une possibilité technique que je ne documenterai pas forcèment car elle ne concerne que les cas compliqués

Mais si j'ai bien suivi ça fait le même boulot, juste différemment, non ?

oui et non, cela sépare les taches et les appels.
Cédric

azerttyu · Mai 20, 2008, 9:13

S'lt

techniquement oui, mais si tu implémente en CVT, ce sont des _dyn et _stat
génériques qui sont pris, ce qui enleve la nécessité de les ecrire. Cette
possibilité existe toujours :
- pour la compatibilité
- pour collecter automatiquement des variables (cf par exemple les forums),
la fonction générique par défaut ne transmettant à charger et consors que
les arguments passés explicitement à la balise.

Toutefois utiliser les 2 en simultanée semblent "dangereux".
Lors d'un test avec le plugin inscription2 (méthode "balise
dynamique"), en mettant en place la couche CVT ça semble foutre un peu
le bordel.
Du coup c'est un nouveau formulaire dédié CVT.

C'est donc une possibilité technique que je ne documenterai pas forcèment
car elle ne concerne que les cas compliqués

SI CVT permet de faire le boulot de _dyn, _stat, il est je pense
pertinent de le documenter.
Les cas tordus (Forum si j'ai bien compris), il n'est pas nécessaire
de l'avoir dans la doc initiale mais faut l'avoir.

C'est un peu "chiant" lorsqu'on découvre des oeufs de pâques.

> Mais si j'ai bien suivi ça fait le même boulot, juste différemment, non ?
oui et non, cela sépare les taches et les appels.

ça c'est de la rhétorique

Km

cerdic · Mai 20, 2008, 9:20

S'lt

techniquement oui, mais si tu implémente en CVT, ce sont des _dyn et _stat
génériques qui sont pris, ce qui enleve la nécessité de les ecrire. Cette
possibilité existe toujours :
- pour la compatibilité
- pour collecter automatiquement des variables (cf par exemple les forums),
la fonction générique par défaut ne transmettant à charger et consors que
les arguments passés explicitement à la balise.

Toutefois utiliser les 2 en simultanée semblent "dangereux".

non, c'est clair :
si la fonction _stat existe, elle est prise a la compile pour definir les arguments, sinon on prend ceux passés à la balise dans le squelette
si la fonction _dyn existe, c'est elle qui est appelée, et la pas de CVT

Lors d'un test avec le plugin inscription2 (méthode "balise
dynamique"), en mettant en place la couche CVT ça semble foutre un peu
le bordel.
Du coup c'est un nouveau formulaire dédié CVT.

faut savoir ce qu'on fait, _stat et _dyn sont un gros bazar à comprendre, donc tant qu'on les utilise, cela reste un bazar.

C'est donc une possibilité technique que je ne documenterai pas forcèment
car elle ne concerne que les cas compliqués

SI CVT permet de faire le boulot de _dyn

oui, _dyn n'a plus d'utilité dans aucun cas d'utilisation de CVT

, _stat, il est je pense

non, _stat peut rester utile dans certains cas, comme avant
Cédric

052d879644199ab5a0b1 · Mai 20, 2008, 9:55

> C'est donc une possibilité technique que je ne documenterai pas
> forcèment car elle ne concerne que les cas compliqués

SI CVT permet de faire le boulot de _dyn, _stat, il est je
pense pertinent de le documenter.
Les cas tordus (Forum si j'ai bien compris), il n'est pas
nécessaire de l'avoir dans la doc initiale mais faut l'avoir.

C'est un peu "chiant" lorsqu'on découvre des oeufs de pâques.

Je ne peux qu'approuver. Il suffit de voir les plugin pour constater que les
gens qui voudraient faire des choses compliquées avec les fomulaires sont
légion...

esj · Mai 21, 2008, 3:25

- formulaire CVT

Charger/Verifier/Traiter est une surcouche des balises dynamiques qui
facilite l'écriture et le dev de formulaires, en séparant bien le
code propre à chaque étape, et son moment d'execution.

...

- un script de traitement dans balises/formulaire_monformulaire.php
-- exploite calculer_balise_dynamique()
-- déclare :
---- balise_FORMULAIRE_MONFORMULAIRE()
---- balise_FORMULAIRE_MONFORMULAIRE_stat()
---- balise_FORMULAIRE_MONFORMULAIRE_dyn()

oui, les deux premieres sont utilisées lors de la compilation, la
troisieme est executée à chaque chargement de la balise.

...

Le corrolaire est que le traitement du formulaire n'est réalisés qu'à
l'affichage de ce formulaire, rendant impossible une redirection
apres traitement.
Les formulaires de forum qui nécessitaient cette redirection
bénéficiaient d'un traitement exceptionnel en dur dans le core

Est-ce la variable d'URL "confirmer_forum" dont tu parles ?
J'avais une balise dynamique perso qui ne marche plus depuis (semble-t-il):
http://trac.rezo.net/trac/spip/changeset/11648#file18
Sur mon site, j'ai surcharché ce code avec l'ancienne version et ça marche à nouveau.
Je suis plutôt content de la disparition de ce cas particulier mais il faut quand même dire clairement que c'est une incompatibilité (j'ai mis du temps à localiser le problème).
As-tu une route à suivre pour résoudre ça de manière moins passéiste ?

Sinon, je suis d'accord avec Camille il faudrait arriver à ne pas mettre dans un même répertoire les .html et les .php.

Committo,Ergo:Sum