Mark Wilson I am the creator of TopXML. I am available for international and local (Australia) contracts. I am a Solution Architect/Business Analyst. I have worked in IT in several countries (NZ, Australia, South Africa, UK) building and training teams for government and very large non-governmental organizations. I am ex-Microsoft Consulting Services. I wrote the first book on Microsoft XML published in 2000 called XML Programming with VB and ASP. Most recently I have been building tools for the SEO industry. Ask me for a 37 point SEO health-checkup for your website.
First posted :
03/24/2008
Times viewed :
636
ASP.NET XML Architecture
ASP.NET is quite a step forward from the original ASP. The ASP
programming model is completely revamped to fit with the rest of the .NET
architecture. ASP.NET presents a fully object-oriented architecture that
promotes the development of well-structured, easy to maintain code and has full
access to every .NET class. Just like classic ASP, ASP.NET pages are
(primarily) templates for HTML pages with the file extension .aspx. The ASP.NET
engine processes the templates in response to an HTTP request and replaces
certain pieces before it is sent to the requester, which is typically a web
browser. In ASP.NET the replaced pieces are either render blocks – the sections
enclosed by <% ... %> containing program code – or special tags that map to
classes in .NET assemblies.
Figure 17.1: ASP.NET creates dynamic content from render
blocks and custom tags.
In contrast to classic ASP, none of the code in an ASP.NET page
is interpreted; it is compiled into an assembly just like any other .NET library
the first time it is requested. Compiling the code renders two additional
advantages over the interpreted model. First, the compilers check code syntax,
method parameters and return values therefore you get more precise error
messages you’re your code contains a bug; it is no longer just the cryptic “ASP
Error”. Second, ASP.NET pages execute faster than classic ASP pages (after the
initial compilation) because compiled code is more efficient than script that
is interpreted for every request.
In addition render blocks and the <script runat=”server”>
tags many of us already know from programming regular ASP pages ASP.NET offers
a third, new option where we can place code. It is a special code file that is
called a “code-behind file”. This file can contain the definition for the base
class of the actual page. The derived class – the page – can access methods and
properties from that base class which makes the code-behind file a good place
for the methods we call from the page template. That keeps the clutter out of
the HTML templates, but more importantly, the code-behind page is built into a
regular .NET assembly as part of the regular build process of a web
application. It is compiled before you deploy a web application to let the
compiler, not the QA department or the user, detect coding errors in your
pages.
The new object-oriented ASP.NET architecture borrows many
concepts from the forms-based user interface model pioneered by Visual Basic.
Each ASP.NET page behaves like a form with a number of interface elements
like text boxes, drop down lists and check boxes. These interface components
are called web controls or server-side controls. We can mix and match the
server-side control to build very complex, interactive pages. Using Visual
Studio.NET, or Microsoft’s free ASP.NET development tool Web Matrix, you can
even design web pages just by dragging and dropping controls onto a forms
designer instead of writing HTML code.
Still, ASP.NET web controls are still nothing but HTML and
JavaScript to enable all sorts of client-side behavior when they reach the
client browser. On the server-side, in the ASP.NET pages, the web controls look
like HTML, which the web forms designer can create for us. Take the form from
this screenshot.
Figure 17.2: Graphical Web Forms Designers allow WYSIWYG
design of ASP.NET pages.
The ASP.NET code for the page looks somewhat like this:
The HTML literate among us will immediately notice that the
<asp:Button> tag is not valid HTML. There is also the runat=”server”
attribute that is not defined by the W3C HTML standard, but is it this
attribute what signals to the ASP.NET engine that this tag represents a
server-side control that needs further processing before sending the page to
the browser. When ASP.NET finds this tag while processing an ASP.NET page it
instantiates a special Button object to handle render the button as HTML. The
object in charge of rendering an <asp:Button> tag, for example, produces
the HTML to render a button on a web page:
