Here's another place where Web form programming differs from Windows form programming—in saving the current state of the data in controls. The problem here is that your data is in a Web page, and the code that works on them is back on the server. Visual Basic makes automatic provision to store the data in Web server controls using HTML hidden fields (that is, HTML <input> elements with the type attribute set to "hidden"), so you don't have to worry about the data in each Web server control (such as the text in a text box). However, what about the variables in your program code? They're reset to their default value each time the page is sent on a round trip to the server, so making sure that the data in your variables is stored is up to you. To see how to do this, see "Saving Program Data across Server Round Trips" in the Immediate Solutions section of this chapter.
There are two possible places to store the data in a page: in the page itself—that is, in the client—and in the server. To see how this works, take a look at "Saving Program Data across Server Round Trips" in this chapter; I'll also take a look at them in overview here.
If you save data in the client, then that data isn't stored on the server. This means the page has to store all the data in each control itself so it can be sent back to the server when the page is posted back to the server. This is the easier way of doing things, because the server doesn't have to "remember" the state of all the applications that it is working with.
The default way of saving the state of the data in Visual Basic controls in Web applications is to use HTML hidden fields. A hidden field stores text data (it's supported with the HTML <input type = "hidden"> element), and in this case, all the data in the controls is stored in encoded text. For example, a Web application page may have a hidden HTML field (which doesn't appear in the browser) that looks like this in HTML:
<input type="hidden" name="__VIEWSTATE" value="dDwxMzI1NzI5NjA3OztsPEltYWdlQnV0dG9uMTs+Pg=="/>
Note that this element uses an XML-style self-closing tag, which ends with />. You'll see this syntax in several places in the HTML that Visual Basic generates. This is the same as if you had explicitly added a closing tag, like this:
<input type="hidden" name="__VIEWSTATE" value="dDwxMzI1NzI5NjA3OztsPEltYWdlQnV0dG9uMTs+Pg=="></input>
You can create and use your own hidden fields to store data in, or if you use the ViewState property, you can use the hidden field that Visual Basic uses for the Web form—see "Saving Program Data across Server Round Trips" later in this chapter for the details.
Besides hidden fields, you also can use browser cookies to store the state of a page in Web applications. There's another option too, if you prefer: Web applications can use query strings, which are made up of information appended to the end of a page's URL after a question mark (?), something like this:
In fact, you also can store an application's state on the server, which provides you with much more security than the client-side options. ASP .NET lets you store an application's state using an application state object (which is an object the HttpApplicationState class) for each active Web application. In this case, the application object is a global storage mechanism accessible from all pages in the Web application and is thus useful for storing information that needs to be maintained between server round trips and between pages.
Besides application state objects, ASP .NET also can store session states using a session state object, which is an object of the HttpSessionState class for each active Web application session. Once you add your session-specific information to the session state object, the Web server manages this object from then on.