Sélectionner une page

Gestion des formulaires et des contrôles de validité (processForm)

Table des matières

Afin de simplifier et d’homogénéiser le traitement des données issues d’un formulaire, une méthodologie a été mise en place par Medsharing. Elle est associée à un ensemble de scripts se trouvant dans le fichier formTools.js. Sauf cas particulier, cette méthodologie doit primer sur toute autre, afin que les membres de l’équipe puisse intervenir facilement. Un développeur professionnel peut également l’appréhender en moins d’une heure, en lisant ce document et en se référant à quelques pages où la technique a été implémentée.

La méthode expliquée ci-dessous permet de procéder à :

  • La vérification côté client des données saisies
  • L’envoi des données au serveur (en mode ajax)
  • La gestion des messages retournée par le serveur, afin d’afficher un message d’erreur
  • En l’absence d’erreur, de poursuivre l’exécution côté client (en général, l’affichage d’une confirmation de traitement ou un rafraichissement de données présentes à l’écran).

Concepts généraux #

  • Comme d’accoutumée le maximum a été fait pour exploiter le potentiel de HTML 5. C’est donc le gestionnaire d’erreurs du navigateur qui fait l’essentiel des vérifications, côté client. Le premier travail du développeur front-end consiste donc à informer les attributs tels que type, required, maxlength, pattern, etc. à l’intérieur de la balise qui le définit. Nous avons ajouté des attributs (data-) qui permettent de personnaliser les messages d’erreur (et qui gèrent le multilingue).
  • Lorsque HTML 5 n’est pas suffisant pour traiter certaines erreurs (par exemple, il ne peut pas comparer deux champs), il convient de créer une fonction JavaScript nommée verfiForm() qui permet de compléter la gestion des erreurs. La structure de la fonction verifForm() doit répondre à des recommandations précises. Elles sont données dans le présent document.
  • Lorsqu’il n’y a pas d’erreur côté client, verifForm() retourne true, et la page ASP est lancée. Cette page a 3 retours possibles :
    • Une chaine sous la forme « err#:message_d_erreur »,  si le serveur détecte une erreur.
    • Le navigateur affiche le message d’erreur, et la main est rendue à l’utilisateurs pour la corriger.
    • La chaine « ok », s’il n’y a pas d’erreur.
  • Le navigateur affiche le message d’erreur, et la main est rendue au script qui execute afterProcessForm(). Cette fonction contient une série d’instructions à exécuter côté client (en général, le rafraîchissement de certains zones d’écran).
  • Si le serveur ne retourne pas l’une des deux chaînes ci-dessus, le script s’interrompt et la suite est exécutée comme un POST classique (comme si nous n’étions pas en Ajax).

Le travail du développeur front-end, consiste donc à créer un formulaire HTML gérant les erreurs prises en charge par le navigateur. Puis, en cas de besoin, une fonction verifForm() qui gère les autres erreurs. S’il existe des erreurs côté serveur, une fonction nommée getInvalidControl devra également être créée pour désigner le champ à commenter. Enfin, une fonction afterProcessForm() termine le processus côté client en exécutant quelques insctructions.

Recommandations côté serveur #

Le script côté serveur qui s’exécute en mode Ajax doit renvoyer :

  • Soit « ok » : lorsque tout s’est exécuté correctement.
  • Soit « err#:message  » : lorsqu’une erreur est interceptée (# étant un chiffre)

Voici un exemple de code ASP/ASPX, traitant les erreurs :

'Code initial permettant de gérer les erreurs
'dans notre exemple, affectation des variables ageMaximum et ageMinimum
[…]
Session("nomFormulaire") = Nothing
If Request("age") > ageMaximum Then
  Response.Write("err1:Cette personne a dépassé l'âge requis")
  Response.End
End If

If Request("age") < ageMinimum Then
  Response.Write("err02:Cette personne n'a pas l'âge requis")
  Response.End
End If
'Autres conditions de traitement d'erreurs
[…]

'Variable de session signalant
'que les données sont correctes
Session("nomFormulaire") = true

'Retour attendu par la fonction Ajax
Response.Write("ok")

La page suivante (celle qu’on afficher lorsque la vérification a réussi) doit commencer par s’assurer que le script de vérification a été exécuté au préalable.

<!--#include file="includes/codepage.asp"-->
<%
If not Session("nomFormulaire") Then
  Response.Write("Cette page nécessite la vérification de certaines données")
  Response.End
End If

'Effacement de la variable de session
Session("nomFormulaire") = Nothing
 […] Suite de la page

Recommandations côté client #

Grâce à différentes fonctions se trouvant dans formTools.js, le formulaire peut être vérifié puis traités en plaçant l’essentiel du code dans la balise <form> et ses sous-balises (input, select, etc.). Le code JavaScript s’en trouve allégé.

La balise <form> #

La syntaxe html du formulaire doit contenir au minimum ces 5 attributs :

<form name="frmNom"
      method="post"
      action="script_.asp"
      onSubmit="javascript:return processForm(this,'pageSuivante.asp');"
      novalidate="novalidate">

(D’autres attributs peuvent être ajoutés, si besoin)

Parties variables #

frmNom :  nom du formulaire (par exemple : frmSignature).

script_.asp : nom du script-serveur à exécuter en mode Ajax (qui renvoient « ok » ou « err#:message_erreur » (voir section précédente).

pageSuivante.asp : optionnel. Nom de la page vers laquelle l’utilisateur doit être redirigé après l’exécution du script-serveur. Lorsque cet argument est absent, il n’y a pas de redirection.

Astuce : pour connaître le message renvoyé par le serveur, il suffit de supprimer onSubmit. Dans ce cas, l’exécution du script ne se fait plus en mode Ajax, et le message du serveur est affiché à l’écran (à utiliser en cas de débogage).

Les champs du formulaire #

HTML 5 propose des attributs qui permettent de vérifier la validité de champs du formulaire (required, minlength, maxlength, pattern, etc).

Tant que possible, il est préférable d’utiliser ces attributs plutôt que des script JavaScript. Les messages d’erreurs peuvent être personnalisés grâce aux attributs data-xxx-message. Ce sont des attributs maison (non-html. Il suffit de les utiliser comme suit :

<input type="password" id="password1" name="password1" class="form-control"
  autocomplete="none"
  spellcheck="false"
  required="required" data-valueMissing-message="Ce champ ne peut être vide"
  minlength="2" data-tooShort-message="Merci de saisir en 2 et 4 caractères"
  maxlength="4" data-tooLong-message="Merci de saisir en 2 et 4 caractères"
  pattern="^[^\s&quot;]*$"
  data-patternMismatch-message="Espaces et guillemets non autorisés" />

Voici la liste des attributs HTML, ainsi que les attributs data-xxx-messages créés par Medsharing pour personnaliser les messages lorsque la saisie est invalide :

Attribut HTMLAttribut du message correspondant
requireddata-valueMissing-message
Si type= »number » et le contenu n’est pas un nombredata-badInput-message
patterndata-patternMismatch-message
maxdata-rangeOverflow-message
mindata-rangeUnderflow-message
Si la valeur d’un type number ne correspond pas au stepdata-stepMismatch-message
maxlengthdata-tooShort-message
minlengthdata-tooLong-message
type= »e-mail » ou type= »url »data-typeMismatch-message

La fonction verifForm(formulaire) #

Cette fonction est nécessaire uniquement dans les cas où les attributs HTML ne suffisent pas. Par exemple, lors du changement de signature, il faut comparer password1 et password2 avant de valider. De plus, les signatures « 0000 » ou « 00000 » sont interdites. Voici une recommandation syntaxique pour les erreurs à gérer en JavaScript :

function verifForm(frm) {
  var obj = null
  var msg = ""
  switch (true) {
    case (frm.password1.value != frm.password2.value):
      obj = frm.password2
      msg = "la confirmation diffère du mot de passe"
      break;
    case frm.password1.value == "0000" || frm.password1.value == "00000":
      obj = frm.password1
      msg = "Le mot de passe saisi est invalide"
      break;
  }
  Return new FormInvalidity(obj,msg)
}

Il ne faut pas exécuter verifForm(). Cette fonction est appelée par processForm() qui se charge de l’ensemble du processus (vérification, exécution, gestion du retour serveur, etc).

La fonction getInvalidControl (formulaire, errCode) #

Cette fonction est utilisée côté client après l’appel au serveur (et la réception du message d’erreur). Elle permet de désigner le champ auquel l’erreur sera affectée et sur lequel le focus devras se placer

Sa syntaxe est celle-ci :

function getInvalidControl(frm, errCode) {
    switch (errCode) {
        case "err1":
            obj = frm.password1
            break;
        case "err2":
            obj = frm.password2
            break;
    }
    return obj;
}

La fonction afterProcessForm (formulaire) #

Cette fonction contient les actions à exécuter après l’appel serveur (si tout s’est passé correctement). La plupart du temps il ‘agit d’un message de confirmation ou de rafraichissements de certaines zones.

function afterProcessForm(frm){
  alert("Votre signature a été modifiée")
}

Avant de commencer #

Pour vous inspirer, vous pouvez vous baser sur les pages suivantes :

  • Change_Signature
  • MessageInvestSend

Elles contiennent tous ces éléments de bout en bout, en bonne et due forme.

Powered by BetterDocs