Let Me Show You the Shiny New Model: The ASP.NET Advantage

   

There are many new advantages to ASP.NET, but I will try to highlight the main points and how they solve some of the problems discussed earlier in this chapter.

The following points best encapsulate how ASP.NET provides a platform for power application development while addressing these nagging problems:

  • Multiple Language Support

  • Code Separation Support

  • Server Controls

  • User Controls

  • Smart Code Output

  • Deployment

Multiple Language Support

Multiple language support is made possible by an ingenious layer of the .NET Framework called the common language runtime. I could spend pages and pages trying to explain all that the common language runtime does with regard to the .NET Framework, but this isn't really the point of this book.

What I will explain is that the common language runtime enables people to write ASP.NET applications in a boatload of languages, both old and new. The most common languages are:

  • Visual Basic .NET

  • C# (Pronounced C Sharp)

  • C++

  • JScript.NET

.NET allows third parties to implement other languages for the common language runtime, and there are languages numbering in the dozens, including Cobol, Pascal, and a version of Java for .NET.

This opens up a world of options for people coming from different backgrounds of design and programming to take advantage of the power of ASP.NET. This is possible because the .NET Framework takes all the languages that are supported and breaks them down into what is called "Intermediate Code."

Basically, .NET has a universal language that it uses no matter what code language you program in. As long as it is a .NET-supported language, you can program your .NET application in it and common language runtime will interpret it down to intermediate code. On top of that, you can program different languages in the same application and .NET is prepared to handle that as well. Your objects are available to each of the different languages no matter what language you are using.

For example, if you are programming just one bit of code in Visual Basic .NET and you create an object while using that language, and you then have someone else in your crew of designers who loves to code in C#, they can access that object as well. Previous to .NET, this was an impossible task. If you needed access to an object, you needed to program in the language that the object was created in. There is power in ASP.NET.

Let's take a look at how we can use different languages, and how .NET can produce the same results. I'll use a similar example to the dreaded "Hello World" example from before, create it in both Visual Basic .NET and C#, and see what results we get.

The following is the example in Visual Basic .NET:

 <script language="vb" runat=server>  Sub Page_Load(Source As Object,E As EventArgs)      labelText.text = "Our VB.NET Example"  End Sub  </script>  <html>  <head>  <title>Multi Language Support   VB.NET</title>  </head>  <body>  <asp:label  runat="server" />  </body>  </html> 

The results are shown in Figure 1.5.

Figure 1.5. The simple example in Visual Basic .NET.
graphics/01fig05.gif

Now here's a similar example in C#:

 <script language="C#" runat="server">  void Page_Load(Object src, EventArgs E){      labelText.Text = "Our C# Example";      }  </script>  <html>  <head>  <title>Multi Language Support - C#</title>  </head>  <body>  <asp:label  runat="server" />  </body>  </html> 

The results are shown in Figure 1.6.

Figure 1.6. The simple example in C#.
graphics/01fig06.gif

As you can see, for the common language runtime it doesn't matter what language you program in. If it is a .NET-supported language, the common language runtime interprets it and converts it to Intermediate Language and processes it exactly the same.

Caution

I specifically wrote the label.Text in the Visual Basic .NET version with the "t" in "text" in lowercase to illustrate that Visual Basic .NET is a bit more forgiving than C#. If "Text" had a lowercase "T" in the C# example, this would have thrown an error that read: 'System.Web.UI.WebControls.Label' does not contain a definition for 'text'. Be careful when referencing object attributes when writing in C# because it's quite picky.


Multiple language support creates a powerful environment in which people from all different backgrounds, with different likes and dislikes, can build .NET applications without prejudice. Gone are the days of arguing over what language is better.

Code Separation Support

As a web designer, if you have done any programming in dynamic languages such as Active Server Pages, you probably have been faced with being confused over code that jumped back and forth between programming logic and physical display code. This has no doubt led to confusion even in circumstances where you were the only person working on a project.

I remember back a few years ago, while I was developing a commerce application, I was faced with loads of conditional code while trying to display the contents of a shopping cart. This page jumped back and forth with all kinds of branches to accommodate if this, that, or the other thing was true. Then we needed to display well, this, that, or the other thing.

Several times I found myself in a trance, staring like a drooling idiot at my monitor, only to be brought back to the present time and place by the burning sensation in my eyeballs from a lack of blinking. The only thing that seemed to help was a break for coffee or an ice cream cone.

Although these things gave me small moments of clarity, they really did little else but give me heartburn or increase my belt size. Out of this a new tag was developed in our firm. We call it the <insanity> tag. Feel free to use it any time you are close to losing your mind. It looks like this:

 <INSANITY>  Insert any totally insane, uninterruptible code here  </INSANITY> 

We have been petitioning the W3C committee to include this in the next standardized version of HTML. I'm sure many web designers would use this on every project. We can only hope.

Another problem with programming web applications is that code reuse was a nightmare at best. It was parallel to untangling a wet, dirty garden hose. Pleasant thought? Neither was the concept of code reuse in traditional ASP. Frankly, I can't think of a single situation where we could easily reuse code from one ASP application to another without picking out the dirt. Bleck!!

But Microsoft has an answer for the <insanity> tag and code reuse problems. It's called code separation. Because ASP.NET is an event-and object-oriented programming model, the concept of code separation is possible. Business logic and display code can be placed in different places within the page.

Let's revert back to traditional ASP and see how you might build a drop-down box from an array of values. If some of this confuses you, don't worry; I'll cover these concepts in greater detail in later chapters.

 <html>  <head>  <title>Code Separation - Traditional ASP</title>  </head>  <body>  <% Dim arrNames(4)  arrNames(0)="Tom"  arrNames(1)="Frank"  arrNames(2)="Bill"  arrNames(3)="Larry"  arrNames(4)="Mike"  %>  <select name="select">  <%for i=0 to Ubound(arrNames)%>  <option value="<%=arrNames(i)%>"><%=arrNames(i)%></option>  <%  Next  %>  </select>  </body>  </html> 

I've highlighted in bold the ASP code to make it easier to spot.

The resulting HTML is exactly as you'd expect:

 <html>  <head>  <title>Code Separation - Traditional ASP</title>  </head>  <body>  <select name="select">  <option value="Tom">Tom</option>  <option value="Frank">Frank</option>  <option value="Bill">Bill</option>  <option value="Larry">Larry</option>  <option value="Mike">Mike</option>  </select>  </body>  </html> 

As you can see with this code, you are moving in and out of HTML and ASP code. This is the reason that ASP has been tagged as a "Spaghetti"-type language. This is just a simple example of code mingling when you're programming in traditional ASP. Even in this small scale, understanding where the programming begins and ends and where the HTML begins and ends is a bit confusing. Imagine more complex situations where you are dealing with data being delivered from multiple tables in a database, with all the other blocks of ASP code blended in. It can become quite a mess.

Now let's look at a small example of how code separation can simplify your development and make your code more readable, as well. The following are ASP.NET examples of the previous ASP code.

Visual Basic .NET
<script language="vb" runat=server>  Sub Page_Load(Source As Object,E As EventArgs)      Dim arrNames(4) as string      Dim counter as Integer      arrNames(0)="Tom"      arrNames(1)="Frank"      arrNames(2)="Bill"      arrNames(3)="Larry"      arrNames(4)="Mike"      For counter = 0 to Ubound(arrNames)          NameList.Items.Add(arrNames(counter))      Next  End Sub  </script>  <html>  <head>  <title>Code Separation - VB.NET</title>  </head>  <body>  <form runat="server">  <asp:dropdownlist  runat="server"/>  </form>  </body>  </html> 
C#
<script language="cs" runat=server>  void Page_Load(Object src, EventArgs E){      string[] arrNames = new string[5];      int counter;      arrNames[0]="Tom";      arrNames[1]="Frank";      arrNames[2]="Bill";      arrNames[3]="Larry";      arrNames[4]="Mike";      for(counter=0;counter < arrNames.Length;++counter){          NameList.Items.Add(arrNames[counter]);      }  }  </script>  <html>  <head>  <title>Code Separation - C#</title>  </head>  <body>  <form runat="server">  <asp:dropdownlist  runat="server"/>  </form>  </body>  </html> 

Once again, I've highlighted the ASP.NET code. Can you see how the programming or logical code has been separated out from the display code? This provides a logical way to create and control the development of programming and interface design separate from each other.

The resulting HTML for both these examples is exactly the same with the exception of the <title>. Look familiar?

Visual Basic .NET
<html>  <head>  <title>Code Separation - VB.NET</title>  </head>  <body>  <select name="NameList" >  <option value="Tom">Tom</option>  <option value="Frank">Frank</option>  <option value="Bill">Bill</option>  <option value="Larry">Larry</option>  <option value="Mike">Mike</option>  </select>  </body>  </html> 
C#
<html>  <head>  <title>Code Separation   C#</title>  </head>  <body>  <select name="NameList" >  <option value="Tom">Tom</option>  <option value="Frank">Frank</option>  <option value="Bill">Bill</option>  <option value="Larry">Larry</option>  <option value="Mike">Mike</option>  </select>  </body>  </html> 

These are the same basic results as traditional ASP produced. The dropdownlist object is smart, as are all the other ASP.NET objects. It knows what HTML to produce without you even telling it.

Microsoft has also provided a way to even further separate out code with a technique called code-behind. Code-behind, simply put, is a technique of placing your programming code in a totally separate file from your display page. I'll take the previous examples and program them with the "code-behind" technique.

First I can create the content page that contains the HTML content code:

Visual Basic .NET
<%@Page Inherits="NameArrayClass" src="/books/1/582/1/html/2/codebehind_vb.vb"%>  <html>  <head>  <title>Code Behind - VB.NET</title>  </head>  <body>  <form runat="server">  <asp:dropdownlist  runat="server"/>  </form>  </body>  </html> 
C#
<%@Page Inherits="NameArrayClass" src="/books/1/582/1/html/2/codebehind_cs.cs"%>  <html>  <head>  <title>Code Behind   C#</title>  </head>  <body>  <form runat="server">  <asp:dropdownlist  runat="server"/>  </form>  </body>  </html> 

These pages contain the content, including the standard HTML tags and the ASP.NET DropDownList server control. Also notice the first line of code, which is called the Page Directive. Think of the Page Directive as what the name seems to imply: directions or instructions for the page. Again, this is covered later in Chapter 4.

Now let's look at the code-behind pages. Again, don't fret at the sight of stuff like "inherits" and "import." This example is just to demonstrate how you can use the code-behind technique to further separate code out.

Visual Basic .NET
Imports Microsoft.VisualBasic  Imports System  Imports System.Web.UI  Imports System.Web.UI.WebControls  Public Class NameArrayClass      Inherits Page      Public NameList as DropDownList      Sub Page_Load(Source As Object,E As EventArgs)          Dim arrNames(4) as string          Dim counter as Integer          arrNames(0)="Tom"          arrNames(1)="Frank"          arrNames(2)="Bill"          arrNames(3)="Larry"          arrNames(4)="Mike"          For counter = 0 to Ubound(arrNames)              NameList.Items.Add(arrNames(counter))          Next      End Sub  End Class 
C#
using System;  using System.Web.UI;  using System.Web.UI.WebControls;  public class NameArrayClass : Page {     public DropDownList NameList;      void Page_Load(Object src, EventArgs E){         string[] arrNames = new string[5];          int counter;          arrNames[0]="Tom";          arrNames[1]="Frank";          arrNames[2]="Bill";          arrNames[3]="Larry";          arrNames[4]="Mike";          for(counter=0;counter < arrNames.Length;++counter){             NameList.Items.Add(arrNames[counter]);          }      }  } 

And the resulting HTML:

Visual Basic .NET
<html>  <head>  <title>Code Behind   VB.NET</title>  </head>  <body>  <select name="NameList" >      <option value="Tom">Tom</option>      <option value="Frank">Frank</option>      <option value="Bill">Bill</option>      <option value="Larry">Larry</option>      <option value="Mike">Mike</option>  </select>  </body>  </html> 
C#
<html>  <head>  <title>Code Behind - C#</title>  </head>  <body>  <select name="NameList" >      <option value="Tom">Tom</option>      <option value="Frank">Frank</option>      <option value="Bill">Bill</option>      <option value="Larry">Larry</option>      <option value="Mike">Mike</option>  </select>  </body>  </html> 

I'm sure you can begin to see the options and advantages of using code separation and code-behind techniques. This also makes the reuse of the programming code a cinch. You can include this file in a zillion other files without having to strip out anything. Just like that instant reusable code.

Throughout this book I will go through some very cool examples of how this frees up designers to be creative with designs without having the programming code getting in the way. I feel, as I'm sure you do, that anything that will free me up to focus on "look and feel" aspects and compartmentalizes programming is a welcome friend.

Server Controls

We have touched (actually just scratched the surface) on server controls in some of the past examples, such as the Label control or the DropDownList control.

Imagine what it would be like if you could design web sites and include advanced stuff by just saying to the browser "Put one of those whatcha callits right here, and a thingy there, and give me a big, blue whosit here." Well, this is a bit of a silly way of saying that ASP.NET gives you that capability.

If you look, you can see that in my silly babble all I was really doing was talking about…what? You guessed it: objects!

I have often thought and discussed with other people in our firm what programming would have been like if someone who was right-brained had named some of the elements used in the programming world. We joke that an object would have been a "thingy."

Server controls are just things used in ASP.NET to return predictable blocks of HTML code to the end user's browser. As you saw with the DropDownList, I simply added values to the list in the Page_Load event from the array, and the DropDownList server control knew what to output.

It created the <Select> tags, as well as the <Option> tags with value attributes, without me ever writing a single <Select> or <Option> tag.

"Great Peter," you say. "But that looks like a plain vanilla drop-down box. This seems like a solution written by a programmer for a programmer who doesn't want to be bothered by coding visual aspects of web design. He just wants to output the data and that's it."

And I say "Patience." There are plenty of sparkly, fun, and exciting aspects for designers, as well, in ASP.NET, and you'd better believe we will be digging deep into that stuff all throughout the book. I can't wait to get to those parts, either, but you must be patient and understand some basic concepts of ASP.NET first.

What ASP.NET provides is a thingy (object) for all the base chunks of HTML code that you need to build ASP.NET applications. From tables, to forms, to images, ASP.NET has an object that is ready to do what you tell it.

There are even a bunch of advanced functioning objects, such as the Calendar server control, that with a single line of code (highlighted in bold)

 <html>  <head>  <title>Calendar</title>  </head>  <body>  <form runat="server">  <asp:Calendar  runat="server" />  </form>  </body>  </html> 

you can produce something as advanced as a fully functioning Calendar with navigation, as shown in Figure 1.7.

Figure 1.7. With a simple single line of code, ASP.NET can produce a very powerful, rich function.
graphics/01fig07.gif

NOW THAT'S TOTALLY AWESOME!!! With a small bit of additional code, you can capture the user's selection and navigate to a different page or whatever your heart desires. All that, and it took me about 30 seconds to code.

The following is the generated HTML from the unmodified Calendar server control. How long do you think it would take you to write this? "A long time" is the answer. Longer than 30 seconds, for sure!

Calendar.aspx
<html>  <head>  <title>Calendar</title>  </head>  <body>  <table  cellspacing="0" cellpadding="2" border="0" style="border-width:1px; graphics/ccc.gifborder-style:solid;border-collapse:collapse;">  <tr><td colspan="7" style="background-color:Silver;">  <table cellspacing="0" border="0" style="width:100%;border-collapse:collapse;">  <tr><td style="width:15%;"><a href="javascript:__doPostBack('Calendar','prevMonth')"  graphics/ccc.gifstyle="color:Black">&lt;</a></td>  <td align="Center" style="width:70%;">December 2001</td>  <td align="Right" style="width:15%;">  <a href="javascript:__doPostBack('Calendar','nextMonth')" style="color:Black">&gt;</a></ graphics/ccc.giftd></tr></table></td></tr>  <tr><td align="Center">Sun</td>  <td align="Center">Mon</td>  <td align="Center">Tue</td>  <td align="Center">Wed</td>  <td align="Center">Thu</td>  <td align="Center">Fri</td>  <td align="Center">Sat</td></tr>  <tr><td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay0')" style="color:Black">25</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay1')" style="color:Black">26</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay2')" style="color:Black">27</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay3')" style="color:Black">28</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay4')" style="color:Black">29</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay5')" style="color:Black">30</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay6')" style="color:Black">1</a>  </td></tr  ><tr><td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay7')" style="color:Black">2</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay8')" style="color:Black">3</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay9')" style="color:Black">4</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay10')" style="color:Black">5</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay11')" style="color:Black">6</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay12')" style="color:Black">7</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay13')" style="color:Black">8</a>  </td></tr>  <tr><td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay14')" style="color:Black">9</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay15')" style="color:Black">10</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay16')" style="color:Black">11</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay17')" style="color:Black">12</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay18')" style="color:Black">13</a>    </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay19')" style="color:Black">14</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay20')" style="color:Black">15</a>  </td></tr>  <tr><td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay21')" style="color:Black">16</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay22')" style="color:Black">17</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay23')" style="color:Black">18</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay24')" style="color:Black">19</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay25')" style="color:Black">20</a>  </td><td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay26')" style="color:Black">21</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay27')" style="color:Black">22</a>  </td></tr>  <tr><td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay28')" style="color:Black">23</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay29')" style="color:Black">24</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay30')" style="color:Black">25</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay31')" style="color:Black">26</a>  </td><td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay32')" style="color:Black">27</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay33')" style="color:Black">28</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay34')" style="color:Black">29</a>  </td></tr>  <tr><td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay35')" style="color:Black">30</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay36')" style="color:Black">31</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay37')" style="color:Black">1</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay38')" style="color:Black">2</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay39')" style="color:Black">3</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay40')" style="color:Black">4</a>  </td>  <td align="Center" style="width:14%;">  <a href="javascript:__doPostBack('Calendar','selectDay41')" style="color:Black">5</a>  </td></tr>  </table>  </body>  </html> 

Are you beginning to see how ASP.NET will help you to concentrate on design, speed up your productivity, and cut down the lines of code you have to write? I thought so.

User Controls

This subject is as juicy as server controls and also is another big part of the equation when it comes to code reuse.

In the past, one of the ways that both designers and programmers tried to reuse code was through Server Side Include files. Server Side Includes were files that contained code "snips" that could be reused in many pages simply by including these file in your ASP or HTML pages. They were a step in the correct direction, but unfortunately they brought some problems with them as well.

One problem with traditional Server Side Includes is that if the file contained images, the images' paths were relative to the include file. You could make image paths absolute by including the full path, but this created problems because the paths in the development environment were very often different from the path of the deployed application.

Another issue in a traditional ASP environment is that Server Side Includes are processed prior to any ASP code. Now that doesn't sound like that big of an issue, but what if you wanted to dynamically decide between loading different include files within your dynamic code? For instance

 <% If variable = 1 then %>  <!--#include file="include1.asp" -->  <%Else%>  <!--#include file="include2.asp" -->  <%End If%> 

In this code block, both include1.asp and include2.asp would fully load. Then the dynamic code would take over after and determine which block to execute. "What's the big deal?" you say. Imagine having ten include files with 100 lines of code each in a statement like this. Your file would contain 900 more lines of code from the 9 unnecessarily loaded pages than needed for what you want to achieve.

As you can see, Server Side Includes are hardly the perfect solution for code reuse, but they were all we had. So we made do.

Now ASP.NET has provided a solution with all the advantages (and more) of the Server Side Include, while resolving the problems associated with it.

User controls can contain images, and the file path issues are resolved properly by the .NET server. This opens up huge doors for design issues and reusing code blocks across multiple pages.

For instance, in my firm we are in the process of developing a content management system for a client that will allow them to build templates by specifying the use of modularized User controls. In other words, the client can specify where a "News" highlight control or a "Hot Point" dialog box appears and create a completely new template in their content management system this way.

In addition, User controls can also be dynamically loaded, allowing many more usable possibilities without sacrificing the application's performance.

One other small issue is that User controls actually are executed in a different process than the file in which they are included. This alleviates some potential problems that conventional include files created with regard to variable name conflicts. With conventional includes, variable names needed to be unique across all included files and the host file as well.

Think of the dynamically selected include file example earlier, and the complications this could create. Most times the differences between the include files in these instances are minimal, with just some small semantic changes. The fact that variables of the same name could and usually were contained in many of the files only added to the problems. ASP.NET User controls make this a moot point.

Smart Code Output

I must mention briefly a super-powerful feature in ASP.NET. It has the capability to produce device-specific code without any intervention by the designer. Did you catch that? Maybe you were so overwhelmed by the statement, you fainted. I'll repeat it again. ASP.NET HAS THE CAPABILITY TO PRODUCE DEVICE-SPECIFIC CODE WITHOUT ANY INTERVENTION BY THE DESIGNER!!!

Being a web designer myself, I don't have to ask if you've been cursed with browser compatibility problems. I know you have! Every web designer has faced this issue with every project.

Suffice it to say that this is an area powerfully addressed by ASP.NET. It can produce code specifically for a boatload of different browsers and devices, including all standard web browsers, many mobile devices, hand-held devices, and more. It also enables you to add definitions for additional devices to accommodate new or existing technologies that are not included in the base .NET Framework.

For instance, ASP.NET has some very powerful form validation server controls. ASP.NET can determine the browser's capabilities and produce browser-specific client-side validation or, if a browser doesn't support this, it can force Server Side validation with you as a designer doing anything but setting some parameters in the server control. All I can say is WOW!

Deployment

Again in the vein of solving problems that are common to web designers, ASP.NET has provided a way for many applications to run on the same server with complete independence from one another, and it has also overcome some of the biggest deployment problems known to people developing ASP applications when using installed components.

The problems are addressed through at least two things that are unique to every possible application on a .NET server. These are an application's Configuration file and the application's bin directory.

Note

The term application is another fancy programmer term used to describe a group of ASP.NET pages that are contained within the confines of a directory or folder. It is the same thing as a web site's root directory. All things contained in that directory are considered part of the web site. The same is true for ASP.NET applications. Everything contained within that root directory is considered part of the application.


The Configuration file, named web.config, is contained in your application's root directory. It is basically an XML file that tells the application how to behave under certain circumstances and situations.

Note

XML (Extensible Markup Language) is an open source language that allows the creation of self-describing, structured information in a standard text document. This is a very powerful concept that is covered in later chapters.


The web.config file isn't necessary for your ASP.NET application to run, but it is available for you to use to further control your application and achieve the results and actions you want. For example, if you want to be able the view detailed errors when you are creating your ASP.NET pages, a simple web.config file might look like the following:

 <configuration>      <system.web>          <compilation debug="true"/>      </system.web>  </configuration> 

Web.config files can contain much more information than this, but this gives you an idea of what a web.config file looks like.

When looking at how ASP.NET has simplified application deployment, you also must consider the use of components. Components are blocks of code that are compiled into a closed file type called a DLL (dynamic link library). The code contained in the DLL is not accessible directly, but you can interact with these components through predetermined methods. I will go into this in more depth as you proceed through the book.

In traditional ASP, components were used for everything from email functionality to file upload functions. The components required some annoying if not disruptive treatment to make them available for use in ASP pages.

First a system's web service would need to be stopped, making the pages on that system unavailable to web browsers. Then the component would need to be copied to the web server. It would need to be registered through a command line execution with Window's RegServ32.exe file. Only then could the web service be restarted. In a shared web hosting environment, many hosting companies won't install custom components at all.

If you created the component yourself and made changes to it, you would need to repeat the process of stopping web service, copying and registering the component, and restarting web service for the changes to be available.

Do you want to hear how you make components available for ASP.NET applications? You copy the component to the bin directory. That's it! Do you want to know how you update a component on the server with a new version? You guessed it! Copy it to the bin directory. What could be simpler than that?


   
Top


ASP. NET for Web Designers
ASP.NET for Web Designers
ISBN: 073571262X
EAN: 2147483647
Year: 2005
Pages: 94
Authors: Peter Ladka

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net