As an improvement, a field FormID can be added to the table Definitions, Lists and Records. FormID uniquely identifies a form, so that the program can define multiple forms at the same time and save user response results for multiple forms. As for the above sTitleLabel, we can save it with another table (such as Forms).
Immediately after the table mark and table title, the program outputs HTML form and the code of the "Submit" and "Clear" buttons. After this, the program checks whether the sHTML string contains "*". If it is included, it means that there is content that must be entered in the form. At this time, a footnote will be output to explain the meaning of the asterisk.
The following is a quoted snippet:
< %=sHTML% >
< TR >
< TD COLSPAN="2" ALIGN="CENTER" >
< INPUT TYPE="SUBMIT" VALUE="Submit Form"> < INPUT TYPE="reset" VALUE="Clear">
< /TD >
< %
'Whether there is a required form field? If there is, the output form footnote explains the meaning of '*'.
If InStr(sHTML,"*") Then
% >
< /TR >
< TD COLSPAN="2" ALIGN="CENTER" >
< FONT SIZE="2" >Note: Values marked with asterisks must be entered. < /FONT >
< /TD >
< /TR >
< %
End If
% >
< /TABLE >
< /FORM >
So far, the form generation task has been completed.
4. Process the submission results
The remaining tasks of ASP scripts are server-side form processing, including verification, saving results to the database, and display of the "Success/Failed Submission" page. In this part of the form verification code, a string variable sBadForm is used, which the program uses to save error information. If sBadForm is empty at the end of the verification process, it means that the form submitted by the user is legal; otherwise, the submission of the form is rejected and the sBadForm is returned to the browser.
Regardless of the verification mode of the form, checking HTTP_REFERER is a good habit. This check can prevent scripts from being stolen. To check if a POST comes from a page or script on this website, just compare two server variables:
The following is a quoted snippet:
If InStr(("HTTP_REFERER"), _
("HTTP_HOST")) = 0 Then
sBadForm = "< LI >Form submitted from an incorrect location." & vbCrlf
End If
If the hidden domain of the form indicates that the server-side verification must be performed, the program traverses the form definition database records for corresponding inspection. The process is very similar to the form generation, except that at this time the program is verifying the form and adding the illegal input value information to sBadForm. See the specific code.
The program finally checks whether sBadForm is empty. If not empty, form submission is rejected and sBadForm is written to the browser. If sBadForm is empty, add a record to the Records table to save form data. Before saving the form content, you need to delete the hidden domain val. This hidden domain is always the first input field of the form:
The following is a quoted snippet:
If Len(sBadForm) = 0 Then
"Records", DB, 3, 2, &H0002
("Record") = Mid(, InStr(, "&") + 1)
("Created") = Now()
("RemoteIP") = ("REMOTE_ADDR")
("< H1 >Thank you.< /H1 >")
Else
("< H1 >Form submission failed.< /H1 >")
(vbCrLf & sBadForm)
End If
End If
This is the entire process of server-side form processing. Depending on whether there is a submitted form, we can encapsulate the code that generated the form and the code that processed here in the form with If statements, so that these two parts of the script share some common code, such as the header of the HTML document, the creation of database objects and the release of resources, etc.
Overall, it only has the core functions necessary for dynamic form generation and verification, and ignores the handling of many detailed problems. For example, the multi-form problem mentioned above: adding one table to manage multiple forms, so that the script has the ability to manage, generate and process specified forms. Another obvious lack is the addition, deletion and update function of form definition data, as well as access to user-submitted result data. This type of function can be implemented in a separate program and in most cases can be made into traditional applications (non-B/S structure applications). Finally, the supported input domain types are also limited, and in practice there may be other form input requirements, such as dedicated e-mail address input boxes, etc. However, for websites that often update forms, the dynamic form generation and dynamic verification functions discussed in this article are indeed very useful.