ASP.NET’s codebehind
structure provides a great way to separate application code from Web page
markup and controls. While it is suitable for most situations, client-side code
is not extinct. There are many situations where client-side code may be more
appropriate and sometimes the best approach. Let’s explore the basics of
client-side code usage and why it may be necessary.

Page structure

An ASP.NET page is comprised of the following elements:

  • Directives: The top of the ASP.NET
    file that controls how a page is compiled, as well as debugging, import
    classes for use on page, and other settings.
  • Controls: Controls are server
    elements that allow dynamic page construction, and often promote user
    interaction with the page.
  • Service-side include
    directives:     The contents of a file may be inserted into a page via
    include directives.
  • Code declaration blocks: Code may
    be included within the page if the codebehind
    model is not used. These blocks are defined within the <script> and
    </script> tags, and the code may be used throughout the page.
  • Code render blocks: Inline code
    may be executed when a page is loaded. In addition, it may utilize code
    defined in a code declaration block.
  • Comments: Server comments may be
    included within <%– and –%> tags.
  • HTML and text: Good old text and
    HTML are the foundation of Web development, and they may be included in
    the page along with CSS, JavaScript, DHTML, and so on.

As this list suggests, an ASP.NET page can become a bit
overwhelming as the number of items included in a page escalate. Also,
client-side code does not mean the codebehind model
is not possible. The two may be combined as necessary depending on the
situation.

You may be thinking that these elements resembled the older
days of classic ASP development. It does seem to be true, but there are
differences. Most notable is the fact that ASP only allowed the VBScript
language. In addition, ASP.NET allows page directives to appear anywhere within
a page while ASP restricted them to the top of the file.

Page elements in action

A simple example can easily demonstrate these elements used
on a sample ASP.NET page. The C# code in
Listing A is a good start. (Listing B
contains the VB.NET equivalent.) The code is simplistic, but it does demonstrate the elements
previously described. First, a couple server-side comments are utilized.
Developers often use such comments as reminders for themselves or fellow
developers. In addition, a code block is included in the header portion of the
HTML. The function (test) is called later in the page. In addition, a couple
inline code blocks are used to display output based upon values passed via the
URL QueryString (name/value pairs appended to page
address). The latter portion of the sample page issues a command to load
another file into that place in the file via the INCLUDE directive. The footer.aspx file includes basic HTML for including a
copyright statement on multiple pages:

<div id="footer">

<b>@2005</b>

</div>

Including the file on multiple pages allows the footer to be
maintained in a central location. ASP.NET provides many other avenues for this
type of functionality with a custom control being the most popular choice. The
last element is the standard HTML that is sprinkled throughout the page with
the most notable element being the header tag (<h1>).

Hiding elements

While the previous example demonstrates the basic usage of
various elements, there may be situations where one approach is necessary to
gain the required functionality. One good example is a recent application that
displayed buttons within a Repeater control based upon the type of user logged
into the application. One other application caveat was the use of JavaScript
and DHTML to present a tabbed interface where individual Repeater controls are
contained on each of three tabs—clicking one tab hid the other two tabs and
displayed the Repeater control for the tab selected.

Each row in the Repeater controls contained an edit button
that was only displayed if the user was a certain type. Initially, button
display was controlled via the Repeater control’s ItemCreated
event. While this did work upon initial page load, all related formatted was
lost when different tabs were selected. That is, the ItemCreated
event was only fired when the page was initially loaded or data control
populated. It was not executed when client-side JavaScript or DHTML was
executed. In fact, any formatting attained via the ItemCreated
event was lost when JavaScript or DHTML code is processed. The workaround was
utilizing client-side inline code to control element display. You may discover
other situations where combining elements provides the desired effect.

Developer options

An ASP.NET page includes many elements that provide the
developer with many options for (often) completing a single task. You may use a
server-side include or develop a custom control for a common footer element for
all pages. In addition, you may place source code in a separate codebehind file or include code declaration blocks within
the ASP.NET page or even utilize inline code. You may reminisce about class ASP
coding when reviewing some of the elements, but they have changed. In the end,
the approach used in your application rests upon the development team.

TechRepublic’s free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically sign up today!