PLASMA UNIVERSITY

DOTNET ( ASP)

Chapter 2. Introducing Active

1
Server [Link] ([Link])
 INTRODUCING ACTIVE
SERVER [Link]
([Link])
In this Chapter will cover :
The Way the Web Works
Dynamic Processing

History of [Link]

Elements of an [Link] Page

Comparison of ASP and

2 [Link]
THE WAY THE WEB WORKS
 The Internet is a wonderful thing. It allows
people from all over the world to communicate
with each other via their computers.
 Originally, Web sites were very simple. There

were HTML pages on any topic, those early

pages were static—visitors couldn’t interact
with them in any way.
 The Web evolved and new levels of functionality

were added, including images, tables, and

forms. This allowed visitors to interact with Web
sites but lacking dynamic content.
 now you can interact with databases, process

content, and determine new types of visitor 3

demographics over the Web

DYNAMIC PROCESSING
 The Internet works on the client/server
model . Two computers work together,
sending information back and forth, to
perform a task. The most common scenario
is communication between a server &
client.
 The client computer sends a request for

information to the server computer. The

server then responds to the client with the
information that was requested of it. This
paradigm(form) is the request/response 4

model
  Model of Client-Server Architecture

The
Web Server (e.g. Microsoft IIS) Internet Client (e.g. Windows 2000)

Request Data Data Keyed

in Out Data

Database

ASP ASP [Link]

Data
Pages pages

5
THE REQUEST/RESPONSE
MODEL
.

6
THE REQUEST/RESPONSE
MODEL
 This model can’t provide any dynamic information or
processing. The server simply waits around for
someone to request information, and then it
returns the data that’s already stored on its hard
drive without really looking at what it’s sending.
 Generally, a static Web request follows these four

steps
[Link] client (the Web browser) locates a Web
server through its URL (such as
[Link] ).
2. The client requests a page (such as [Link]).
3. The server sends the requested document.
4. The client receives the document and displays it.
7
THE REQUEST/RESPONSE
MODEL
 Once the client has received the
information, the process is finished. The
server has no idea what’s happening on
the client ,since the server and client are
two separate computers?
 They only communicate with one another

during the request response process. Once

the page has been delivered, the server
doesn’t care what happens

8
ENTER SERVER PROCESSING
 This comes in many forms, including the
common gateway interface (CGI) and
Microsoft’s Active Server Pages (classic ASP. ).
 The server takes a look at what it sends

before it sends it, and it can take orders from

the client.
[Link] client (the Web browser) locates a
Web server through its URL (such as
[Link] ).
2. The client requests a page (such as
[Link]).
3. The server examines the requested file9
and processes any code it contains.
ENTER SERVER PROCESSING
4. The server translates the results of
the processing to HTML (if necessary)
and sends the requested document
to the client.
5. The client receives the document
and displays it
 Even in this scenario, the process is

over once the client receives the page.

The server has no idea what the client
is doing unless it makes another 10
request.
THE [Link] DIFFERENCE
 There’s another model for communicating
between servers and clients, known as the
event-driven model .
 The server waits around for something to

happen on the client. Once it does, the

server takes action and performs some
piece of functionality.
 Web server can’t know what you’re
thinking, but it can respond to your
actions. If you type some text on the Web
page or click an image, the server 11

responds to it.
THE [Link] DIFFERENCE
 How can [Link] know what’s going on in
your computer? How can the server react
to things happening on the client? [Link]
relies on clever client-side processing to
simulate an event-driven model.
Client-Side Processing
 Client-side processing occurs when you
place some programming code in an HTML
page that the client can understand.
 So now you have two places to execute

code: on the server, where everything is

returned to the client as HTML, and on the12
client. They cannot interact with each other
 The Differences Between Client-Side and Server-Side
Code
Location Description

[Link] code isn’t processed at all by the

server. That’s solely the client’s responsibility.
[Link] is written in scripts—plain-text
Client
side commands that instruct the client to do
something.
[Link] used for performing dynamic
client effects, such as image rollovers.
1. This code is executed only on the server.
Any content or information that this code
produces must be converted to plain HTML
Server before being sent to the client.
side 2. Code can be written in scripts as well, but
[Link] uses com-piled languages (more on
that later). 13
3. Used for processing content and returning
data.
HOW [Link] TIES IT
TOGETHER
 So how does [Link] know what’s going
on with a client? The only way for a
client to communicate with the server is
during a request.
 Using client-side script, [Link] supplies

information about what the client is

doing during requests
 [Link]’s spies are client-side scripts.

Whenever something happens on the

client, a client-side script executes and 14
sends information to the server
HISTORY OF [Link]
 Prior to ASP, developers were able to
create active Web sites on a Microsoft
platform using the Common Gateway
Interface (CGI) and Internet Server
Application Programming Interface (ISAPI),
which played a part in the evolution of ASP.
 CGI was the first widely accepted

technique of delivering dynamic Web

content. Active Server Pages (ASP)
technology has been introduced in 1996.
 Early in 2002, Microsoft released a new
15
technology for Inter net development
called ASP .NET
 WHAT IS [Link]?
 [Link] is a server-side technology for
developing web applications based on the
Microsoft .NET Framework.
 Since the processing of the [Link] code

occurs on the server, it ’s called a server-

side technology.
 ASP .NET has full access to the functionality

of the .NET Framework. Support for XML, web

services, database interaction and many
other technologies are built right into .NE
 ASP .NET allows you to separate the server- 16

side code in your pages from the HTML

ELEMENTS OF AN [Link]
PAGE
 the <%@ Page %>directive, which supplies
the [Link] page with specific information
that’s used during the compiling process.
 In this case, you’re telling [Link] that

you’re using the Visual [Link]

programming language to write your code.
 <head runat="server“> contain a block of

code called a code declaration block. This

looks similar to the client-side code that you
learned about earlier today in “Client-Side
processing,” but it includes a new tag,
17
runat=”server”.
ELEMENTS OF AN [Link]
PAGE
 This is the code that [Link] uses to
process its pages, and it’s where you’ll
control all the functionality. This code is also
compiled into MSIL.
 <% [Link](“Our First

Page<p>”) %> This is known as a code

render block. It contains additional
instructions that [Link] uses to produce
output. In this case, it tells [Link] to write
“Our First Page "to the browser. Code render
blocks aren’t compiled, and as such they’re
18
not as efficient as code declaration blocks.
ELEMENTS OF AN [Link]
PAGE
 <asp:Button ID="Button1"
runat="server" Text="Submit" />
 you have a few new elements that look

like HTML elements. These are known as

Web controls. Often they perform very
similarly to HTML elements, but with
added functionality that [Link] can
use. Notice that each of these items
also has the runat=”server” line.
19
COMPARISON OF ASP AND
[Link]
 ASP also made it abundantly clear that client
and server were two separate entities. Once
ASP was finished with its work on the server,
it passed the HTML to the client and forgot
about it. [Link] ties together the client and
the server through clever use of server-side
and client-side code, all invisible to the
developer
 In classic ASP, nearly all of the code was

executed in code render blocks (that is, inside

 <%...%>tags). In [Link], this type of code

isn’t compiled and isn’t recommended for 20

frequent use.
COMPARISON OF ASP AND
[Link]
 Inaddition, [Link] is now completely
object-oriented. Classic ASP strove to
introduce the concept of object-
oriented programming (OOP), but was
unable to because that was a
fundamentally different programming
paradigm.

21
SUMMARY
 This section examined some typical
[Link] pages. We learned about the
most common parts of an [Link] page,
including the <%@ Page %> directive,
code declaration and render blocks, and
Web forms. These all provide the
foundation for building complex [Link]
pages.
 The most important point to take away

from today’s lesson is that [Link]

pages are a server technology that 22

enables you to build dynamic Web pages

 PROGRESS
CHECKING
 What’s server computer and client computer?
 client-side scripts can’t exactly interact with

the server-side, how they can relay messages

to the server?
 Describe functions of the following:

I. Script tag <script>

II. Runat server tag <runat=“server”>

 List reasons for avoiding clien t-side

programming .
 What’s the difference between code
23
declaration blocks and render blocks?