Source View and HTML
Source View and HTML
The source code that describes a Web Form is, in various forms, easily visible to both the developer and the end user of the application. For Windows Forms applications, any textual representation of the form layout is not generally directly manipulated by the end user, and only with great difficulty is it manipulated by the developer.
The fact that Visual Studio considers the underlying text representation important enough to make it one of the two views, Source view and Design view, tells you something about the importance of the text representation of forms. Although Design view has improved greatly in the latest version of Visual Studio, some things are still easier in Source view. For instance, creating complex HTML table layouts (which will be described in Chapter 3) can be much easier to do in Source view than in Design view.
It is significant that in earlier versions of Visual Studio, the view now known as Source view was called HTML view. HTML stands for Hypertext Markup Language. To fully understand HTML, it is important to understand what a markup language is. A markup language consists of a set of labels that are embedded within text to identify portions of the text for identification or display purposes. The labels are often referred to as tags, and in many markup languages, these tags are identified by enclosure between less than (<) and greater than (>) characters. HTML generally uses tags to identify portions of text for different display features, such as bold, italic, and underline. HTML also contains tags that allow you to format blocks of text, such as the paragraph (<p>) tag and the break tag (<br />).
| Note | Most markup languages follow a very precise structure, with no variation allowed. They are considered unparsable if not well formed. Well formed can mean several things, but important among the features of a well-formed document is that each element has a beginning tag and an end tag. This requirement can be met in two ways. Often, it is met by two completely separate tags. For example, text can be marked as bold in HTML by being placed within an opening <b> tag and a closing </b> tag. Alternately, tags can be self closing. The break tag (used to cause text to break to the next line) can be well formed by using a self-closing tag (<br />). Many Web pages and even HTML references use the break tag (and a variety of other tags) that contain only an opening tag (a break tag would be <br>). Although most browsers accept this sort of broken markup, it is not, strictly speaking, correct. HTML grew up around some other real browser implementations, many of which allowed or even encouraged sloppiness. For instance, the Microsoft Internet Explorer 3.x browser would properly handle a Web page that contained an opening tag for a table but no closing tag. Other browsers (notably Netscape) did not. Developers who tested only on Internet Explorer often created pages that did not work correctly in other browsers, even when the "broken" browser was expecting the document to be in the correct format. My intention in this book is to create markup in which all opening tags are closed (or are self closing) and all tags are nested correctly. Please let me know if you see any place where I have fallen short! |
Although text in Source view looks like HTML, it is not completely normal HTML. A few items that are not standard HTML appear in the source text of the Web page, but for now I will focus on the controls I added to the page: the label, text box, and button. Any tag in an ASP.NET page that begins with <asp: is an ASP.NET Web control. In the tag, asp represents the namespace the control resides in. Namespaces are used in many areas to allow an object to be uniquely identified. For example, if multiple developers created controls named textbox, as long as the controls existed in different namespaces, they could be referenced on the same page without any ambiguity. Later in this book, namespaces will be used in code so that the code can be uniquely identified.
If the source code shown in Source view is not proper HTML, how can the page be viewed in a browser? Rather than guess, the best way to determine what will happen is to run the application. When you click Start Debugging on the Debug menu (or simply press F5), you see a dialog box like the one shown in Figure 1-8.
Figure 1-8: The dialog box prompting you to create a Web.config file before debugging in Visual Studio
This message appears because Visual Studio 2005 does not create a default Web.config file when the Web site is created. The Web.config file can be used to configure many aspects of the Web site's performance. Visual Studio 2005 prompts you to create the Web.config file only when needed. Click OK to allow Visual Studio to create a Web.config file that will allow the program to run and be debugged.
| Note | Another significant difference between Visual Studio 2005 and earlier versions is the way in which Web sites are managed. In Visual Studio .NET 2003, a project file (with a .prj extension) was created along with a new Web site. The project file contained several settings, as well as a list of files to be included when the Web site was compiled. Visual Studio 2005 uses a "projectless" model. There is no project file, and rather than the entire project being compiled in advance into a single dynamic link library (.dll) file, individual page files, as well as other code files, are compiled into individual .dll files. The individual .dll files are not stored or saved (like the single .dll file in Visual Studio .NET 2003 that was stored in the bin folder). There are other implications of this change. In earlier versions, you could exclude files from the project in Solution Explorer. In Visual Studio 2005, when you exclude a file, an .exclude file extension is added. ASP.NET will not try to compile a file with the extension .exclude. |
When you run the application, a browser appears as shown in Figure 1-9.
Figure 1-9: The sample Web application running in Internet Explorer
The resulting Web Form shows a label, text box, and button, just as we would expect. One of the beauties of Web development is that whenever we want to see how something works, all we need to do is look at the HTML source in the browser. By clicking Source on the View menu in Internet Explorer, you can see that the source for the resulting Web page looks like the following.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head><title> Default Page </title></head> <body> <form method="post" action="Default.aspx" > <div> <input type="hidden" name="__VIEWSTATE" value="/wEPDwUKMTIxNDIyOTM0MmRk9bZa8LK8gUtQI0UvnFGr1uITvLw=" /> </div> <div> <span >Label</span><br /> <input name="TextBox1" type="text" /><br /> <input type="submit" name="Button1" value="Button" /></div> </form> </body> </html>
Although this source looks similar to the code in Figure 1-7, the Web controls (identified by the <asp: in the beginning of their tags) have been replaced by standard HTML tags.
This transition, from the ASP.NET markup on the server to proper HTML on the client, is the key to understanding how ASP.NET works. A Web Form is requested by a client (generally using a browser). The server responds to the request, converting the ASP.NET markup on the server to HTML markup that is sent to the client.
| Note | Only HTML (and possibly JavaScript) actually runs on the client when an ASP.NET application runs. An important implication of this is that the Microsoft.NET Framework need not be on the client machine. Also, both the Web server and the browser are often running on the same machine when a Web Forms application is being created. I will have more to say on this subject later in this chapter. |
A Web application communicates between client and server (again, even if both are running on the same machine) using Hypertext Transfer Protocol (HTTP). HTTP is a stateless protocol. This means that, rather than the client browser and Web server establishing a connection when the user first enters a site and dropping the connection only when the user leaves the site, each and every request for a page establishes a connection, transfers information, and closes the connection. Although this is great for performance and scalability of a Web site, it is inconvenient for many applications.
Although HTTP is a stateless protocol, ASP.NET does a good job of hiding that fact. When a client first connects to a Web application, ASP.NET establishes a session. A session can contain information that is added by the Web Forms and then retrieved later. There are limits to what can and should be stored in session state. Most importantly, session state can be a significant drag on server resources if the number of sessions is quite large or if session state for individual clients is quite large.
In addition to session state, ASP.NET maintains another important type of state for the developer, which is view state. This type of state maintains the form's control values between postings. Let's look back at the sample Web application shown in Figure 1-9. If you enter some text in the text box and click the button, the text you entered is still in the text box when the page is redisplayed. Given what I have said about each request being a new request to the server, and given that we have not added any code to persist the text entered into the text box, how does the text get repopulated? The answer is in the HTML code shown previously. The significant bit of source code is this line.
<input type="hidden" name="__VIEWSTATE" value="/wEPDwUKMTIxNDIyOTM0MmRk9bZa8LK8gUtQI0UvnFGr1uITvLw=" />
This is a standard HTML tag declaring an input element, with type hidden, meaning that it is not visible when the page is rendered in the browser. The value attribute of this tag contains encoded text that is the key to persisting values between postbacks. This is a tag used by ASP.NET to remember state information between postbacks. This special __VIEWSTATE HTML control is used to maintain page-level information between postbacks. The information maintained in this way is called view state. Rather than maintaining state on the server, view state is maintained inside the page and sent from the server to the client and back again.
View state is useful for maintaining values on a single page, and it will be covered in more detail later in this chapter.
| Note | A postback is what we call it when a Web Form is posted back to itself. When a screen is first presented to the user, this is not a postback. When the user clicks a submit button and the server-side code is executed, this is a postback. |
