developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 13 years ago

Closed 13 years ago

#258 closed new feature (fixed)

jforms: control reset

Reported by: laurentj Owned by:
Priority: low Milestone: Jelix 1.0 RC1
Component: jelix:forms Version: trunk
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Documentation needed:
Hosting Provider: Php version:

Description

Ajout d'un control <reset> dans jForms, qui afficherait un bouton reset dans le formulaire, au même niveau que les submits.

Attachments (3)

jelix-trunk-#258.patch (39.5 KB) - added by bibo 13 years ago.
jelix-trunk-#258.2.patch (39.5 KB) - added by bibo 13 years ago.
jelix-trunk-#258.3.patch (48.0 KB) - added by bibo 13 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.0 to Jelix 1.2

comment:2 Changed 13 years ago by bibo

Première tentative de patch.

Description du patch :

  • support du tag <reset> dans les descriptions xml de formulaires. le tag peut contenir les balises communes <label>, <hint>, <help>.
  • ajout d'un plugin de template de type fonction {formreset} qui doit être utilisé dans {form}.
  • prise en charge du controle <reset> pour {formfull ...}
  • génère un controle html de type : <button type="reset" .../>

Le patch ne contient pas de tests unitaires mais je peux me pencher sur la question.

comment:3 Changed 13 years ago by bibo

J'ai fait attention de générer le patch à partir du root svn et de travailler avec les sources en UTF-8 pour ne pas avoir les mêmes soucis que sur mon patch du ticket 362. J'espère que ce sera mieux cette fois.

comment:4 Changed 13 years ago by laurentj

{{{ lib/jelix/forms/jFormsBase.class.php @@ -563,6 +575,8 @@

$this->_controls [$control->ref] = $control; if($control->type =='submit')

$this->_submits [$control->ref] = $control;

+ if($control->type =='reset') + $this->_reset = $control;

if($control->type =='upload'){

$this->_uploads [$control->ref] = $control;

}

}}}

Peut être que du coup, là, on pourrait utiliser un switch, ou au moins des else if

lib/jelix/forms/jFormsBuilderBase.class.php
-        }else if($ctrl->type != 'submit'){
+        }else if($ctrl->type != 'submit' || $ctrl->type != 'reset'){
C'est un &&, pas un
lib/jelix/forms/jFormsControl.class.php
+class jFormsControlReset extends jFormsControlDatasource {
+    public $type='reset';
+    public function check($value, $form){
+        return null;
+    }
+}

Pourquoi hériter de jFormsControlDatasource ? À priori il n'y a qu'un reset par formulaire, et on ne génère pas plusieurs reset à partir d'une datasource. D'ailleurs je crois que tu ne verifie pas dans le compilateur l'unicité de la balise Reset. À rajouter donc.

lib/jelix/plugins/tpl/html/cfunction.formfull.php
@@ -68,6 +69,8 @@
         echo \'</td></tr>\';
     }
     echo \'</table> <div class="jforms-submit-buttons">\';
+    if ( $ctrl = $formfull->getReset() )
+        $formfullBuilder->outputControl($ctrl);
     foreach( $formfull->getSubmits() as $ctrlref=>$ctrl){
         $formfullBuilder->outputControl($ctrl);
         echo \' \';

J'afficherai plutôt le reset après les boutons submit, non ? qu'en penses tu ?

Sinon dans l'ensemble ça m'a l'air correct :-)

J'aimerais bien des tests unitaires, ainsi que l'ajout dans le sampleform de test app d'un reset pour qu'on puisse tester en "réèl" que je puisse voir ce que ça donne.

comment:5 Changed 13 years ago by bibo

lib/jelix/plugins/tpl/html/cfunction.formfull.php
@@ -68,6 +69,8 @@
         echo \'</td></tr>\';
     }
     echo \'</table> <div class="jforms-submit-buttons">\';
+    if ( $ctrl = $formfull->getReset() )
+        $formfullBuilder->outputControl($ctrl);
     foreach( $formfull->getSubmits() as $ctrlref=>$ctrl){
         $formfullBuilder->outputControl($ctrl);
         echo \' \';

J'afficherai plutôt le reset après les boutons submit, non ? qu'en penses tu ?

Et bien si on se place dans l'optique reset=annuler, submit=valider, en général sur une interface desktop, ou dans une boite de dialogue le bouton annuler apparait toujours à gauche ou avant le bouton valider. C'est dans cette optique que j'ai place le reset avant les submits.

Cependant, le bouton reset dans un browser ne fait juste que réinitialiser les champs modifiés et est donc moins significatifs que les submits qui renvoient vers une autre page potentiellement.

Je serais tout de même d'avis de le générer avant, à charge du CSS et du design de le différencier des submits (en le rendant moins important) si besoin.

J'aimerais bien des tests unitaires, ainsi que l'ajout dans le sampleform de test app d'un reset pour qu'on puisse tester en "réèl" que je puisse voir ce que ça donne.

Je vais voir ça et aussi les remarques sur le premier patch

comment:6 Changed 13 years ago by laurentj

si on se place dans l'optique reset=annuler, submit=valider, en général sur une interface desktop, ou dans une boite de dialogue le bouton annuler apparait toujours à gauche ou avant le bouton valider. C'est dans cette optique que j'ai place le reset avant les submits.

Sauf que ce n'est pas le cas de toutes les interfaces, ça dépend vraiment du système que tu emploi. C'est pour ça que je m'interroge...

comment:7 Changed 13 years ago by bibo

Sur quel système/interface a-t-on valider puis annuler ? Je viens de regarder sur une ubuntu et le premier dialogue de ce style met annuler puis valider. sur windows, c'est pareil.

D'un point de vue purement conceptuel, je trouve que valider doit plutôt être le dernier choix après toutes les vérifications effectuées. En ce sens, le bouton annuler permet de faire réfléchir une dernière fois avant validation.

Changed 13 years ago by bibo

Changed 13 years ago by bibo

comment:8 Changed 13 years ago by bibo

Un second patch qui corrige les coquilles du précédent repérées par laurent.

J'ai ajouté aussi le test de l'unicité du tag <reset> dans une description de formulaire. J'espère avoir respecté lers bons charset sur la localisation du message d'erreur formserr.notunique.tag.

Enfin, sampleform dans testapp permet de voir en vrai ce que ça donne :-) Par contre, je ne me suis pas engagé dans les tests unitaires.

comment:9 Changed 13 years ago by bibo

Au fait, mon éditeur est réglé pour supprimer les esapces en fin de ligne, ce qui fait que mes patchs sont un peu pollués par ces modifications.

D'un autre côté, ça nettoie le code source. Mais enfin si ça gène, je peux modifier ça.

Changed 13 years ago by bibo

comment:10 Changed 13 years ago by bibo

Troisième version avec les test unitaires.

Les tests unitaires ont névessité une factorisation du code de jFormCompiler::compile() pour en extraire la methode generatePHPContent.

Les tests unitaires m'ont aussi permis de corriger une coquille sur le plugin html ctrl_value.

comment:11 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.2 to Jelix 1.0 RC1

comment:12 Changed 13 years ago by laurentj

  • Resolution set to fixed
  • Status changed from new to closed

Review+ Intégré dans le trunk. Merci pour le patch !

Note: See TracTickets for help on using tickets.