To execute form submissions for multiple pages in ASP

Let's say you want to create a multiple-page order form on your site so that you can perform the email to the order writer from the site and assume that the individual pages, the number of pages, and the input fields on the page will change depending on the product you are actually ordering. If we submit each page to the FrontPage Email Wizard or the CGI email program separately, then the poor order writer will receive a separate email message for each page of the order. Of course, we can pass order data from one page to another through a session variable, a hidden field, or a query string, but storing this data in memory can create an imbalance in the application and potentially require a large number of scripts. And when the field on the page changes, you have to modify the script code, so the code is not very able to reuse. It would be great if you could write a script that could be used on all of these order pages, leaving only the design of the HTML page to the Web designer. A simple answer is to save the data from each page in a single file, then connect all the files and send them to the order writer by email. Another advantage of this approach is that if you are willing to keep the temporary files on your hard disk, users can continue to have an unfinished order later. Best of all, implementing this method requires no Third-party components, but only session variables, ASP scripts, and Scripting.FileSystemObject objects. The first thing to do is to determine a unique name for these individual paging data files so that they can be put together at the end of the order and will not be overwritten by other files in the application. Also, you need to aggregate the files represented by a single session variable so that you don't accidentally include the data from an old session into the current order. The session variable ("SessionID") provided by IIS is uniquely recognized on the network server during a sessions, but at the end of the process, it can be replicated. (In fact, SessionID is always replicated in subsequent session sessions, SessionID is stored in a cookie in the client.) When a network server receives a SessionID of a past session from the client, it uses the same value if it is not used by another active session, so that you do not have to send another cookie to the browser, which you can refer to on Microsoft MSDN managing Sessions. To uniquely identify the session, we want to create our own session recognizer session ("Sessiontoken"), using the time test method: Attach the date and time to the SessionID. Sub Setsessiontoken Dim dttemp Dim sdate Dim stime dttemp = Date Sdate = year (dttemp) & Month (dttemp) & Day (dttemp) Dttemp = time Stime = Hour (dttemp) & Minute (dttemp) & Second (dttemp) Session ("Sessiontoken") = Session.SessionID & "-" & Sdate & "-" & Stime End Function By encapsulating the Setsessiontoken as a function, you can easily modify the algorithm to generate a session flag without affecting other parts of the code. Setsessiontoken will be invoked at the top of the first page order. Each page must have a unique page number, which is appended to the session flag variable to produce a filename. You can use any kind of logo for the page, but in this application, the page must be output in the order in which it was entered, so use a page number that captures this order. As in front, the file name algorithm is encapsulated into a function, which can be easily modified later.　 Function buildfilename (ipage) '--if the session has expired, return a null filename. If session ("Sessiontoken") = "" Then Buildfilename = "" Else Buildfilename = Session ("Sessiontoken") & IPa GE & ". txt" End If End Function The Writepage function is called at the top of each page after the first page of the order to write the data submitted from the previous page to the file. This function is also called after the last page. Function writepage (iprevpage) Dim sfilename Dim objFSO Dim objTS Dim Objfield sFileName = Buildfilename (iprevpage) Set objFSO = CreateObject ("Scripting.FileSystemObject") Set objTS = objFSO.OpenTextFile (sFileName, 2, True) '--this is the using for ...　Each on the Request.Form ' collection does is not return the fields in any ' specific order. For each objfield in Request.Form '--write one field per line to the output file, name = value objTS.WriteLine Objfield & "=" & Request.Form (objfield) Next Objts.close Set objts = Nothing Set objFSO = n Othing End Function Remember that each page's data is written to the file by a later page, so the second page must know that it follows the first page, and so on. With a session variable currdatapage the current form data page number from the beginning of the page to the Writepage () call to the next page, rather than using the hard encoding of each page number in the call. In a moment you'll see that the program that combines all the page numbers to know what the last page number is, so use a subroutine to assign a value to the currdatapage and see if it's the last page page. <% Sub Setcurrpage (Ipagenum) If Ipagenum > Session ("Maxdatapage") Then Session ("maxdatapage") = Ipagenum End If Session ("currdatapage") = Ipagenum End Sub % > This way, each page (except the first page) is at the top of the script < body > area: <% Writepage (Session ("Currdatapage")) Setcurrpage ({This page ' s number}) % > and the first page script is: <% Setsessiontoken Setcurrpage (1) % > The last page of the data will be submitted to a confirmation page, which is the standard step on any ecommerce site. Our situation requires a confirmation page to provide an opportunity to write out the data for the last-page order and to establish a file to transmit the data. (If you don't want to use a confirmation page, you can also use a script to redirect to a pure ASP page at the end.) ） The Getalldata function returns the combined values of all data elements entered in different pages. Function getalldata Dim sfilename Dim I Dim objFSO Dim objTS Dim Sline Dim Sbody Dim I NumPages Inumpages = Session ("Maxdatapage") Sbody = "" Set objFSO = CreateObject (" Scripting.FileSystemObject ") '--Retrieve pages in Page-number order for I = 1 to inumpages sFileName = Buil Dfilename (I) '--not all pages exist to every order If objfso.fileexists (sfilename) Then Set objTS = obj Fso. OpenTextFile (sFileName, 1) Do While not objts.atendofstream sline = objts.readline Sbody = sbody & Sline & vbCrLf Loop Objts.close Set objts = Nothing End If Next Set objFSO = nothing< br> getalldata = sbody End Function Note that the Getalldata function uses the carriage return newline character (Carriage-return) combination at the end of each line instead of the HTML < BR > element. If you display all order data with inline text or HTML on the confirmation page, this will be a very long page. If you do this, the key part of the user interface, "User response buttons and controls," is pushed beyond the visible part of the screen, so that this page is far from being very user friendly. To make the page not too long, you can display the order data in a scrolling text box instead of using all of the HTML. To review this data, users must use scrollbars, but they do not have to scroll through the entire browser window. You can display the order by embedding some ASP scripts in the < TEXTBOX > element's value clause: < FORM method= "POST" action= "mailer.asp" > < TEXTAREA rows= "> <% Response.Write Getalldata% > </textarea ></form > The processing of the onfocus event is not given to the ASP, but is performed by the client's JavaScript. Use the < TEXTAREA > element as a scrolling display box The problem is that users can type on top of the data displayed in the box. This.blur () causes the focus to be on the next control so that the user cannot type in the text area. They can select text from the text area and even place the text pointer in it, but they can't actually modify it. If you are concerned about typing in the data validation display, you may not use JavaScript, and the alternative is to use a hidden field that populates the ASP in addition to the text area that is actually displayed. Depending on the layout of your page, you can even process two text areas into separate forms so that the user sees this one not as part of the Submit button form. Now all the data is in a single form, you can use the FrontPage file or email wizard to process it, or use CDO or MAPI methods to email them. To send an HTML-formatted email, replace the carriage return line feed with the < BR > element in the combined order description. If you need to support both formats, you can add a second argument to the Getalldata to indicate whether the output requires direct text or HTML formatting. Advantages and Disadvantages The value of any one tool or method depends on the problem that you are trying to solve and the specific environment. Now look at both sides of this approach: Advantages 0 No third party control is required; 0 does not require any client form processing (except for a bit of JavaScript on the confirmation page, which is optional); 0 scripts are well separated from HTML. Most scripting code is at the top and bottom of the page; 0 Minimum memory requirements. Disadvantage 0 More disk space is required, at least temporarily; 0 more disk input and output, under the lightweight-medium server load, may be slower than the solution in memory; 0 uses the session variable (see for more details)advantages and disadvantages of using session variables）。 Conclusions This method of dealing with multiple-page forms is easy to understand and straightforward to implement, but there are many areas that need to be strengthened clearly. First, you can store temporary data in another way, possibly a database. Another possibility is to use an XML file, which eliminates the need for a separate data file for each page, and can take advantage of the Microsoft XML Decomposition tool: The IE5 and XMLDOM APIs. XML files are more easily used by other applications and are easier to document. Especially in a multiple server environment, we might choose to use the Session object to manage sessions. There are two good articles on the management techniques of the session variable, Jeff Benson.Serialize Your session with a homegrown state Management Component for ASP", and Craig McQueen."Maintaining user state with the Active User Object (AUO)"。 Finally, we may want to change the way that the session identification number is created. By combining the user account with the date and time of the order, the user is allowed to restart a previously unfinished order. Alternatively, you can store the previous session identification number in a cookie and reload it into the next session. ClickhereDownload the relevant documentation for this article.