 |
DevSource RSS FEEDS | |
| |
 Want an easy way to keep up with breaking tech news? And the Get DevSource headlines delivered to your desktop with RSS. | |
| | ||
2005-09-07
Article Rating:
/ 7
| Table of Contents: |
| Rate This Article: | Add This Article To: |
|
( Page 2 of 4 )
In the previous installment of this series, Incorporating Classes with Master Pages, you discovered that it's relatively easy to extend the functionality of master pages by modifying the basic classes. Some developers might think that the additional functionality of classes means that scripting is dead. However, scripts still perform a number of useful purposes. You might be surprised to learn that ASP.NET 2.0 adds some scripts for you. These automatic scripts handle tasks such as creating cookies and tracking control state.
Scripting takes three common forms in an ASP.NET 2.0 application. First, you can create a script the old-fashioned way, by incorporating it as part of the content of the Web page. You use this form of script to perform local tasks based on user interaction, conditions such as the type of browser, or on events such as loading the page. Second, you can rely on ASP.NET 2.0 to create a script for you based on the code behind you write. Saving a cookie on the client requires a script, no matter what technique you use to write the code to perform the task.
Finally, you can use new techniques, such a script injection, to create a script under conditions that would normally preclude script usage. This article concentrates on the second and third form of scripting, because the Internet already contains a wealth of articles about the first form.
Understanding Master Page Issues
Master pages introduce an added level of complexity into the script scenario, but also provide a means of reducing script maintenance. The added complexity comes in a number of forms. One of the most problematic is that you lose control over the <body> tag on the content page when working with a master page. Many scripts depend on the <body> tag because it provides the onload event that many scripts require to perform a task automatically when the page loads. The only way to overcome this problem is to use an injection script — a technique discussed later in this article.
Another problem is one of unintended side effects. A master page script can inadvertently affect the output of a content page in a way that prevents either script from performing the required tasks. Normally, good troubleshooting techniques help, but sometimes you need to look at the composite page as well to see what ASP.NET is actually outputting to the client.
Using master pages can also have positive effects on scripting. For example, you can place a common script on the master page, rather than repeat it in each content page. Using this approach means that you can make changes to one script location, rather than making multiple changes to each content page. The down side is that you must ensure the script is generic enough to meet the needs of every content page.
|
|
 |
|
 |
|
|
|