Le formulaire dit complexe fait ici référence à un formulaire qui contient plusieurs types d'entrée différents, tels que des zones de liste déroulante, du texte sur une seule ligne, du texte sur plusieurs lignes, des valeurs numériques, etc. Dans les situations où de tels formulaires doivent souvent être remplacés, un programme de génération dynamique du formulaire est requis. Cet article présente un tel système, qui utilise une base de données pour enregistrer les données de définition de formulaire et utilise des scripts ASP pour générer dynamiquement des codes HTML de formulaire et des scripts pour vérifier les entrées du formulaire.
1. Définissez la structure des tables de la base de données.
Vous pouvez souvent voir des formulaires tels que « Enquête hebdomadaire » sur le Web. Il s'agit d'un formulaire qui doit être mis à jour fréquemment. S'il existe un programme qui génère dynamiquement des formulaires et leurs scripts de validation, la charge de travail liée à la création de ces formulaires peut être considérablement réduite.
Dans l'exemple de génération et de validation de formulaire dynamique présenté dans cet article, nous utilisons une base de données Access pour stocker les informations de définition du formulaire. En même temps, pour plus de simplicité, les données saisies par l'utilisateur dans le formulaire sont également enregistrées dans la même base de données. . La définition d'un formulaire nécessite deux tables : la première table (Définitions) est utilisée pour définir les champs de saisie du formulaire, et la deuxième table (Listes) enregistre des informations supplémentaires sur chaque champ de saisie, telles que les éléments de sélection de la liste de sélection.
La table Definitons contient les champs suivants :
FieldName - le nom de la variable attribué au champ de saisie du formulaire.
Étiquette - étiquette de texte, le texte informatif affiché devant le champ de saisie
Type - un seul caractère, qui représente la forme du champ de saisie du formulaire et le type de la valeur d'entrée, comme suit :
(t) Zone de saisie de texte, c'est-à-dire < INPUT TYPE="TEXT" >.
(n) Une zone de saisie de texte, mais nécessite une valeur numérique.
(m) Contenu de la note, utilisé pour la saisie de commentaires ou d'autres grandes quantités de texte, il s'agit d'une zone d'édition de texte multiligne.
(b) Nécessite la saisie de « oui » ou de « non ». Dans cette implémentation, une case à cocher sera utilisée pour obtenir cette entrée, le texte de la case à cocher étant "Oui". Si l'utilisateur le sélectionne, la valeur de retour est "on".
(r) Bouton radio.
(l) Zone de liste déroulante.
Min - valable uniquement pour les valeurs d'entrée numériques, la valeur minimale est indiquée ici. Dans cet exemple, il y a une zone de saisie numérique « Âge » avec sa valeur minimale définie sur 1.
Max – La valeur de ce champ est relative au formulaire de champ de saisie. Pour les zones de saisie numérique, cela représente la valeur maximale autorisée. Par exemple, la valeur maximale de « Âge » est de 100. Pour les zones de saisie de texte, Max représente le nombre maximum de caractères autorisés. Pour les zones d'édition de texte multilignes, Max représente le nombre de lignes de texte dans la zone visible.
Obligatoire : indique si une entrée est requise. Si une valeur de ce type n'est pas saisie, le validateur d'entrée signalera une erreur. Dans le formulaire, les valeurs qui doivent être saisies sont marquées d'un astérisque et l'utilisateur est invité sous la forme d'une note de bas de page que ces valeurs doivent être saisies.
L'exemple de formulaire présenté dans cet article est un questionnaire de programmeur ASP. La définition du formulaire dans la table Définitions est la suivante :
FieldName Type d'étiquette Min Max Requis
Nom Texte du nom (t) - 50 Non
Âge Numéro d'âge (n) 1 100 Non
Sexe Bouton de sélection unique du sexe (r) - - Oui
Texte de l'adresse e-mail (t) - - Oui
Zone de liste déroulante du langage de programmation (l) - - Non
Les listes sont utilisées pour enregistrer certaines informations supplémentaires définies dans le champ de saisie. Dans cet exemple, "Sexe Il est utilisé pour les deux valeurs d'entrée" et "Langues". Le tableau Lists est très simple et ne contient que les trois champs suivants :
FieldName - à quel champ de saisie du formulaire appartient l'enregistrement actuel.
Value - la valeur de la sélection
Label - le texte d'invite de la sélection que l'utilisateur voit
. Le champ de saisie "Sex" ne peut être saisi qu'à partir de Deux valeurs au choix : "Homme" ou "Femme". "Langage" répertorie plusieurs langages de programmation pouvant être appliqués à l'environnement ASP, notamment : VBScript, JavaScript, C, Perl et "Autres".
La troisième table « Enregistrements » enregistre le contenu soumis par l'utilisateur. Elle contient également trois champs. Chaque enregistrement correspond à une soumission par l'utilisateur :
Enregistrement - Type de remarque, saisie utilisateur enregistrée sous forme de chaîne de requête.
Créé – La date et l'heure auxquelles l'utilisateur a soumis le formulaire. RemoteIP - L'adresse IP de l'auteur du formulaire.
Dans les applications réelles, il peut être nécessaire de collecter davantage d'informations sur les utilisateurs. Par souci de simplicité, cet exemple n'enregistre que deux informations supplémentaires : l'heure de soumission et l'adresse IP de l'utilisateur.
2. Préparation
Après avoir terminé la définition de la structure de données et du formulaire ci-dessus, vous pouvez ensuite écrire le script. Le travail du script consiste à générer des formulaires et à traiter les formulaires soumis par les utilisateurs.
Qu'il s'agisse de générer ou de traiter un formulaire, les trois processus (tâches) suivants sont essentiels : Le premier consiste à déterminer le type de validation Lors de la génération du formulaire, la valeur du type de validation est obtenue via la chaîne de requête, et lorsque le formulaire est traité. , les champs masqués du formulaire sont obtenus Lire. Il existe quatre types de méthodes de vérification de formulaire prises en charge par le programme : aucune vérification, vérification JavaScript côté client, vérification de script ASP côté serveur et vérification côté client et côté serveur (les noms de code sont respectivement de 0 à 3). Si aucune méthode d'authentification valide n'est spécifiée dans la chaîne de requête, la quatrième méthode d'authentification est utilisée par défaut. Cette méthode de traitement de vérification nous permet d'appliquer de manière flexible ce système de génération et de traitement de formulaires. Lorsque le client interdit l'utilisation de la vérification JavaScript, le processus de vérification ne peut être effectué que côté serveur. Voici le code pour déterminer le type de validation :
Vérifier le type de validation.
Voici l'extrait de citation :
iValType = Request.QueryString("val")
Si IsNumeric(iValType) = False Alors iValType = 3
Si iValType > 3 Ou iValType < 0 Alors iValType =3
La deuxième tâche consiste à ouvrir une connexion à la base de données et à créer deux objets Recordset : l'objet RS, qui est l'objet Recordset principal de ce programme, utilisé pour faire fonctionner la table Définitions ; l'objet RSList, principalement utilisé pour lire les données de la table Lists. L'exemple de programme propose deux méthodes de connexion à la base de données : en utilisant ODBC DSN ou sans ODBC DSN (lors de l'utilisation de DSN, vous devez d'abord créer un DSN nommé Dynamic, et le code permettant d'utiliser DSN pour se connecter à la base de données a été commenté).
La troisième tâche consiste à générer du code HTML statique avant (et après) la génération (ou le traitement) du script de formulaire, tel que <HEAD>< /HEAD>, et à libérer les objets RS, RSList et autres objets occupés à la fin du script. .
En plus du code qui effectue les tâches ci-dessus, il existe deux types de pages qui peuvent être générées par les scripts ASP restants dans l'exemple d'application : le formulaire de questions (voir l'image ci-dessus) et la page de résultats qui apparaît après l'envoi du formulaire. soumis (ce dernier se charge également d'enregistrer les résultats soumis par l'utilisateur) . Le moyen le plus simple de déterminer quelle partie du script exécuter est de vérifier si le formulaire a été soumis : si c'est le cas, traitez le formulaire sinon, générez le formulaire.
S'agit-il de générer un formulaire ou de traiter un formulaire ?
Voici un extrait de citation :
Si Len(Request.Form) = 0 Alors
'Générer un formulaire... légèrement...
Autre
'Traitez le formulaire... légèrement...
Fin Si
3. Générer dynamiquement le formulaire
Lors de la génération du formulaire, le programme définit les enregistrements en fonction de chaque champ de saisie dans la table Définitions et génère tour à tour le code HTML et le code JavaScript du formulaire correspondant. La première chose à générer dans le code HTML est la balise de texte :
Voici l'extrait de citation :
sHTML = sHTML & vbTab & "< TR >" & vbCrLf & vbTab & vbTab
sHTML = sHTML & "<TD VALIGN=" & Chr(34) & "TOP" & Chr(34)
sHTML = sHTML & " >" & vbCrLf & vbTab & vbTab & vbTab
sHTML = sHTML & "<B >" & RS.Fields("Étiquette")
Le programme vérifie ensuite si le champ de saisie actuel nécessite une saisie. Si nécessaire, ajoutez un astérisque après le texte de l'étiquette (indiquant que la valeur doit être saisie), et pour la valeur qui doit être saisie, le code JavaScript correspondant doit être généré pour la vérifier. Pour les boutons radio ou les listes de sélection, il existe une vérification supplémentaire que l'utilisateur a effectivement sélectionné une option pour tous les autres types d'entrée, il suffit de vérifier que la valeur d'entrée n'est pas vide.
Après l'étiquette de texte se trouvent les éléments d'entrée du formulaire, et le code HTML de ces éléments est généré en fonction des types et des attributs spécifiés dans le tableau Définitions. L'étape suivante consiste à générer du code JavaScript qui effectue des tâches de vérification côté client en fonction des exigences de valeur d'entrée. Pour cet exemple, seules les valeurs numériques nécessitent une vérification supplémentaire pour garantir que la saisie de l'utilisateur est bien un nombre et que la valeur numérique se situe entre les valeurs maximales et minimales autorisées. Après avoir généré le code ci-dessus, vous pouvez terminer une ligne du tableau (c'est-à-dire un champ de saisie) et continuer le traitement de l'enregistrement suivant du tableau Définitions. Une fois que tous les enregistrements de la base de données ont été traités, l'étape suivante consiste à ajouter le code HTML pour le bouton « Soumettre » et le bouton « Effacer ». Si vous le regardez sous un autre angle, la tâche du programme ici est de générer chaque champ de saisie en fonction de l'enregistrement de la base de données. Chaque champ de saisie occupe une ligne du tableau, et chaque ligne du tableau comporte deux cellules : la première cellule est utilisée pour afficher. étiquettes de texte, et la seconde L'unité affiche l'élément d'entrée lui-même (voir dForm.asp pour le code).
Une fois le processus ci-dessus terminé, le code HTML du formulaire et la fonction JavaScript de validation sont respectivement enregistrés dans les variables sHTML et sJavaScript. Avant d'écrire ce contenu sur la page, le programme vérifie si le client nécessite une validation JavaScript. Si une telle validation n'est pas requise, la variable sJavaScript est effacée :
Si iValType = 0 Ou iValType = 2 Alors sJavaScript = ""
Après la sortie de la balise BODY, le programme génère la fonction JavaScript suivante :
Ce qui suit est un fragment de citation :
< LANGUE SCRIPT="JavaScript" >
< !--
fonction valider(TheForm){
//Validation du formulaire client
< %=sJavaScript% >
renvoie vrai ;
}
fonction CheckRadio(objRadio){
//Si une valeur dans le bouton radio est sélectionnée
pour(var n = 0; n < objRadio.length; n++){
si(objRadio[n].checked){
renvoie vrai ;
}
}
renvoie faux ;
}
fonction CheckList(objList){
//Si une valeur a été sélectionnée dans la liste de sélection
pour(var n = 1; n < objList.length; n++){
if(objList.options[n].selected){
renvoie vrai ;
}
}
renvoie faux ;
}
//-- >
</ /Script >
Si le client ne nécessite pas de validation JavaScript, la fonction de validation se retrouve avec une instruction « return true ». Les deux dernières fonctions JavaScript statiques (CheckRadio et CheckList) dans le code ci-dessus sont utilisées pour valider les boutons radio et les listes déroulantes. La fonction de validation les appellera lorsque ces deux champs de saisie doivent être validés.
Vous pouvez maintenant commencer à écrire le formulaire sur la page :
< FORM ACTION="./dform.asp" METHOD="POST" NAME="MyForm" onSubmit="return validate(this)" >
Ici, uniquement si la fonction de validation renvoie true Ensuite seulement, effectuez l'opération de soumission du formulaire. Par conséquent, lorsque la fonction de vérification JavaScript côté client est désactivée, la fonction de validation renvoie automatiquement true.
La prochaine chose à ajouter est un champ caché appelé val. Comme mentionné précédemment, cette valeur indique le mode de validation du formulaire.
< INPUT TYPE="HIDDEN" NAME="val" VALUE="< %=iValType% >" >
Lorsque l'utilisateur soumet le formulaire, le script de traitement utilisera cette valeur pour déterminer s'il doit effectuer une validation côté serveur.
Ensuite, le résultat est la marque du tableau et le titre du tableau. Le titre est enregistré dans la variable sTitleLabel, dont la valeur est initialisée au démarrage de l'exécution du script :
Voici l'extrait de citation :
< BORDURE DU TABLE="0" >
<TR>
< TD COLSPAN="2" ALIGN="CENTRE" >
< H2 >< %=sTitleLable% >< /H2 >
< /TD >
< /TR >
À titre de mesure d'amélioration, un champ FormID peut être ajouté aux tables Définitions, Listes et Enregistrements. FormID identifie de manière unique un formulaire, afin que le programme puisse définir plusieurs formulaires en même temps et enregistrer les résultats des réponses utilisateur de plusieurs formulaires. Quant au sTitleLabel ci-dessus, nous pouvons utiliser une autre table (telle que Forms) pour le sauvegarder.
Après la marque du tableau et le titre du tableau, le programme génère le formulaire HTML et le code des boutons « Soumettre » et « Effacer ». Après cela, le programme vérifie si la chaîne sHTML contient "*". Si c'est le cas, cela signifie qu'il y a du contenu qui doit être saisi dans le formulaire. À ce stade, une note de bas de page est affichée pour expliquer la signification de l'astérisque.
Voici une citation :
< %=sHTML% >
<TR>
< TD COLSPAN="2" ALIGN="CENTRE" >
< INPUT TYPE="SUBMIT" VALUE="Soumettre le formulaire" > < INPUT TYPE="reset" VALUE="Effacer" >
< /TD >
<%
'S'il existe un champ de formulaire qui nécessite une saisie, si c'est le cas, affichez la note de bas de page du formulaire pour expliquer la signification de '*'
Si InStr(sHTML,"*") Alors
%>
< /TR >
< TD COLSPAN="2" ALIGN="CENTRE" >
< FONT SIZE="2" >Remarque : les valeurs marquées d'un astérisque sont obligatoires. < /POLICE>
< /TD >
< /TR >
<%
Fin si
%>
< /TABLE >
</ /FORMULAIRE >
Jusqu'à présent, la tâche de génération de formulaire est terminée.
4. Traitement des résultats de soumission
Les tâches restantes du script ASP sont le traitement du formulaire côté serveur, y compris la validation, l'enregistrement des résultats dans la base de données et l'affichage de la page « Succès/Échec de la soumission ». Une variable chaîne sBadForm est utilisée dans cette partie du code de validation du formulaire et le programme l'utilise pour enregistrer les informations d'erreur. Si sBadForm est vide à la fin du processus de vérification, cela signifie que le formulaire soumis par l'utilisateur est légal, sinon la soumission du formulaire est rejetée et sBadForm est renvoyé au navigateur ;
Quel que soit le mode de validation utilisé par votre formulaire, il est conseillé de vérifier HTTP_REFERER. Cette vérification empêche le vol de script. Pour vérifier si un certain POST provient d'une page ou d'un script de ce site Web, comparez simplement deux variables du serveur :
Voici l'extrait de citation :
Si InStr(Request.ServerVariables("HTTP_REFERER"), _
Request.ServerVariables("HTTP_HOST")) = 0 Alors
sBadForm = "<LI>Le formulaire a été soumis à partir d'un emplacement incorrect." & vbCrlf
Fin si
Si le champ masqué du formulaire indique qu'une vérification côté serveur doit être effectuée, le programme parcourt les enregistrements de la base de données de définition du formulaire et effectue les vérifications correspondantes. Le processus est très similaire à la génération du formulaire, sauf que cette fois, le programme vérifie le formulaire. formulaire et ajoute des informations de valeur d'entrée illégales à Accédez simplement à sBadForm. Voir dForm.asp pour le code spécifique.
Le programme vérifie enfin si sBadForm est vide. S'il n'est pas vide, la soumission du formulaire est rejetée et sBadForm est écrit dans le navigateur. Si sBadForm est vide, ajoutez un enregistrement à la table Records pour enregistrer les données du formulaire. Le champ masqué val doit être supprimé avant d'enregistrer le contenu du formulaire. Ce champ masqué est toujours le premier champ de saisie du formulaire :
Ce qui suit est un fragment de citation :
Si Len(sBadForm) = 0 Alors
RS.Ouvrir "Enregistrements", DB, 3, 2, &H0002
RS.AddNew
RS.Fields("Enregistrement") = Mid(Request.Form, InStr(Request.Form, "&") + 1)
RS.Fields("Créé") = Maintenant()
RS.Fields("RemoteIP") = Request.ServerVariables("REMOTE_ADDR")
RS.Mise à jour
Réponse.Write("< H1 >Merci.< /H1 >")
RS.Fermer
Autre
Response.Write("< H1 >La soumission du formulaire a échoué. < /H1 >")
Réponse.Write (vbCrLf & sBadForm)
Fin si
Fin si
C'est tout pour le traitement des formulaires côté serveur. Selon qu'il existe ou non un formulaire soumis, nous pouvons encapsuler ici le code de génération de formulaire précédent et le code de traitement du formulaire avec une instruction If, afin que les deux parties du script partagent un code commun, tel que l'en-tête du document HTML, la création d'objets de base de données et la libération des ressources attendent.
Dans l'ensemble, dForm.asp ne dispose que des fonctions de base nécessaires à la génération et à la vérification de formulaires dynamiques et ignore la gestion de nombreux problèmes détaillés. Par exemple, le problème des formulaires multiples mentionné précédemment : l'ajout d'une table pour gérer plusieurs formulaires permet au script d'avoir la capacité de gérer, générer et traiter les formulaires spécifiés. Un autre manque flagrant est la possibilité d'ajouter, de supprimer et de mettre à jour les données définies par le formulaire, ainsi que l'accès aux données de résultats soumises par l'utilisateur. Une telle fonctionnalité pourrait être implémentée dans un programme autonome et, dans la plupart des cas, transformée en un programme autonome. application traditionnelle. (Applications sans structure B/S). Enfin, les types de champs de saisie pris en charge par dForm.asp sont également limités. En pratique, il peut y avoir d'autres exigences de saisie de formulaire, comme une zone de saisie d'adresse e-mail dédiée. Cependant, pour les sites Web qui mettent fréquemment à jour les formulaires, les fonctions de génération de formulaires dynamiques et de validation dynamique abordées dans cet article sont en effet très utiles.