In the previous article, the author introduced in detail how to use the ASP built-in object Response. In this article, the author will continue to introduce to you two other very practical and important ASP built-in objects Application and Session.
In addition to objects used to send, receive, and process data, there are also some very practical objects representing Active Server applications and individual user information in ASP.
Let's take a look at the Application object first. All .asp files in the same virtual directory and its subdirectories constitute the ASP application. Instead of using Application objects, we can share information among all users of a given application and save data persistently during server operation. Furthermore, the Application object also has methods to control access to application-level data and events that can be used to trigger a process when an application starts and stops.
Let’s learn about Application objects together.
1. Attributes
Although the Application object does not have built-in properties, we can set user-defined properties using the following syntax, which can also be called collections.
Application(Property/Collection Name)= Value
We can declare and create properties of the Application object using the following script.
< %
Application(MyVar) = Hello
Set Application(MyObj) = Server.CreateObject(MyComponent)
%>
Once we assign the properties of the Application object, it persists until the WEB server service is shut down so that Application stops. Since the values stored in the Application object can be read by all users of the application, the properties of the Application object are particularly suitable for passing information between users of the application.2. Method
Application objects have two methods, both of which are used to handle multiple users writing data stored in Application
1. The Lock method prohibits other customers from modifying the properties of the Application object.
The Lock method prevents other customers from modifying variables stored in the Application object to ensure that only one customer can modify and access Application variables at the same time. If the user does not explicitly call the Unlock method, the server will unlock the Application object after the .asp file ends or times out.
Let's take a look at the following program that uses Application to record the number of page accesses:< %
Dim NumVisitsNumVisits=0
Application.LockApplication(NumVisits) = Application(NumVisits) + 1
Application.Unlock
%>
Welcome to this page, you are the < %= Application(NumVisits) %> visitor on this page!
Save the above script in your .asp file and add a counter to your page easily.
2. Contrary to the Lock method, the Unlock method allows other customers to modify the properties of the Application object.
In the above example, in the above example, the Unlock method unlocks the object so that the next client can increase the value of NumVisits.
III. Events
1. Application_OnStart
The Application_OnStart event occurs before the first creation of a new session (i.e. the Session_OnStart event). The Application_OnStart event is triggered when the WEB server starts and allows requests to files contained in the application. The processing of the Application_OnStart event must be written in the Global.asa file.The syntax of the Application_OnStart event is as follows:
< SCRIPT LANGUAGE=ScriptLanguage RUNAT=Server>
Sub Application_OnStart. . .
End Sub
< /SCRIPT>
2. Applicati
on_OnEnd
The Application_OnEnd event occurs after the Session_OnEnd event when the application exits. The processing of the Application_OnEnd event must also be written in the Global.asa file.
Let's take a look at some things you must pay attention to when using Application objects.
ASP built-in objects cannot be stored in Application objects. For example, each line below returns an error.
< %
Set Application(var1)=Session
Set Application(var2)=Request
Set Application(var3)=Response
Set Application(var4)=Server
Set Application(var5)=Application
Set Application(var6)=ObjectContext
%>
If you store an array in an Application object, do not change the elements stored in the array directly. For example, the following script cannot run.
< % Application(StoredArray)(3) = new value %>
This is because the Application object is implemented as a collection. Array element StoredArray(3) No new assignment was obtained. This value will be included in the Application object collection and will overwrite any information previously stored at this location. It is recommended that you obtain a copy of the array before retrieving or changing the objects in the array when storing the array in the Application object. When operating on an array, you should store all the arrays in the Application object so that any changes you make will be stored. The following script demonstrates this.
---asp8a.asp---
< %
dim MyArray()
Redim MyArray(5)
MyArray(0)=hello
MyArray(1)=some other string
Application.Lock
Application(StoredArray)=MyArray
Application.Unlock
Response.Redirect asp8b.asp
%>
---asp8b.asp---
< %
LocalArray=Application(StoredArray)
LocalArray(1)= there
Response.Write LocalArray(0)&LocalArray(1)
Application.Lock
Application(StoredArray)=LocalArray
Application.Unlock
%>
Another very practical ASP built-in object that has similar functions to Application objects is Session. We can use the Session object to store the information needed for a specific user session. When the user jumps between pages of the application, variables stored in the Session object are not cleared, and these variables always exist when the user accesses the page in the application. When a user requests a web page from the application, if the user has not had a session, the web server will automatically create a Session object. When the session expires or is abandoned, the server terminates the session.
Session objects on the server can be managed by sending unique cookies to the client program. When a user requests a page in the ASP application for the first time, the ASP checks the HTTP header information to see if there is a cookie named ASPSESSIONID in the message. If so, the server will start a new session and Generate a globally unique value for the session, and send this value to the client as the value of the new ASPSESSIONID cookie. It is precisely using this cookie to access information belonging to the client program stored on the server. The most common function of a Session object is to store user preferences. For example, if the user indicates that he does not like to view the graphics, he can store the information in a Session object. In addition, it is often used in programs that identify customers. It should be noted that the session status is only retained in browsers that support cookies, and if the customer turns off the cookie option, Session will not work.
1. Attributes
1. SessionID
Ses
The sionID property returns the user's session identity. When creating a session, the server generates a separate identity for each session. The session identifier is returned as the elongated data type. In many cases SessionID can be used for WEB page registration statistics.
2. TimeOut
The Timeout property specifies a timeout time limit for the Session object of the application in minutes. If the user does not refresh or request a web page within this timeout period, the session will terminate.
2. Method
There is only one method for a Session object, which is Abandon. The Abandon method deletes all objects stored in a Session object and releases the source of these objects. If you do not explicitly call the Abandon method, the server will delete these objects once the session timed out. When the server has finished processing the current page, the following example releases the session state.
< %Session.Abandon %>
III. Events
The Session object has two events that can be used when the Session object is started and released is run.
1. The Session_OnStart event occurs when the server creates a new session. The server processes the script before executing the requested page. The Session_OnStart event is the best time to set session variables, because they are set before accessing any pages.
Although the Session object remains when the Session_OnStart event contains a Redirect or End method call, the server stops processing the Global.asa file and triggers the script in the file that triggers the Session_OnStart event.
To ensure that the user always starts a session when opening a specific web page, the Redirect method can be called in the Session_OnStart event. When the user enters the application, the server creates a session for the user and processes the Session_OnStart event script. You can include the script in this event to check if the page opened by the user is a startup page, and if not, instruct the user to call the Response.Redirect method to start the web page. The procedure is as follows:
<SCRIPT RUNAT=Server Language=VBScript>
Sub Session_OnStart
startPage = /MyApp/StartHere.asp
currentPage = Request.ServerVariables(SCRIPT_NAME)
if strcomp(currentPage,startPage,1) then
Response.Redirect(startPage)
end if
End Sub
< /SCRIPT>
The above programs can only run in browsers that support cookies. Because browsers that do not support cookies cannot return SessionID cookies, the server creates a new session whenever a user requests a web page. This way, for each requesting server, the Session_OnStart script will be processed and the user will be redirected to the startup page.
2. The Session_OnEnd event occurs or timed out during the session.
Things to note about using Session objects. Application objects are similar, please refer to the previous article.
The session can be started in the following three ways:
1. A new user requests access to a URL that identifies the .asp file in an application, and the Global.asa file of the application contains the Session_OnStart process.
2. The user stores a value in the Session object.
3. The user requested an application's .asp file, and the application's Global.asa file uses the <OBJECT> tag to create an instance of an object with a session scope.
If the user does not request or refresh any pages in the application within the specified time, the session will automatically end. The default value for this period is 20 minutes. You can change the default timeout limit settings for an application by setting the session timeout property in the Application Options property page in the Internet Service Manager. This value should be set according to the requirements of your web application and the server's memory space. For example, if you want users who want to browse your web application to stay on each page for only a few minutes, you should shorten the default timeout value for your session. An overly long session timeout value will cause too many open sessions and exhaust your server's memory resources. For a specific session, if you want to set a timeout value that is smaller than the default timeout value, you can set the Session object's
Timeout property. For example, the following script sets the timeout value to 5 minutes.
< %Session.Timeout = 5 %>
Of course, you can also set a timeout value greater than the default setting. The Session.Timeout property determines the timeout value. You can also explicitly end a session through the Abandon method of the Session object. For example, provide an exit button in the table, setting the ACTION parameter of the button to the URL of the .asp file containing the following commands.
< %Session.Abandon %>
Today, we have learned two built-in objects that often use ASP on WEB pages, especially on WEB-based BBS or Chat. Since these two objects are very practical in actual application, the author will apply what we have learned in the next article. The 4 built-in ASP objects I have demonstrated a complete ASP application to you. I believe that through this exercise, you can greatly deepen your understanding and mastery of ASP applications. Please pay attention to the eighteen martial arts of dynamic website design--ASP (9).