Web applications basics Codebehind and code inline models

web applications basics
codebehind and code inline models


web application
is an application that is accessed by users over a network such as the internet or an intranet.[] the term may also mean a computer software application that is coded in a browser-supported programming language (such as javascript, combined with a browser-rendered markup language like html) and reliant on a common web browser to render the application executable.

web applications are popular due to the ubiquity of web browsers, and the convenience of using a web browser as a client, sometimes called a thin client. the ability to updating and maintain web applications without distributing and installing software on potentially thousands of client computers is a key reason for their popularity, as is the inherent support for cross-platform compatibility.


a web server is a piece of software that enables a website to be viewed using http. http (hypertext transfer protocol) is the key protocol for the transfer of data on the web. you know when you re using http because the website url begins with "http://" (for example, "http://www.quackit.com").

you might be thinking "i always thought a web server was a special, high-powered computer". well, you d be right too. some high-powered computers are referred to as web servers as they have been built with web hosting in mind. but in most cases, when someone refers to a web server, they are referring to a piece of software that you install on a computer.

when a web browser talks to a web server, it uses something called a universal remote identifier (uri). the uri has multiple components but starts by telling the server the protocol that it wants to use. the protol that a web server supports is http . other protocols that could be presented by a browser are ldap, ftp, and mailto. unfortunately a web server does not know how to handle these protocols and would return an error.

the role of iis
iis fulfills the role of the web server, responding to requests for files from web clients such as ie, and logging activity.

iis maintains information about the location of content files, what security identities have access to those files, how content files are separated into applications, and what urls are mapped to those applications. this information can be configured manually or programmatically by using one of the iis administration technologies.

iis can communicate with software such as microsoft sharepoint, microsoft visual studio.net, and web distributed authoring and versioning (webdav) to make web content creation fast and easy. web content can be created to take advantage of one of the iis development technologies. the role of iis in the client/server relationship iis 7
web browser
web browser as a computer program used for accessing sites or information on a network (as the world wide web). this is a simple, yet accurate description. web browsers come in many different styles, each with their own nuances. however, the main reason a person utilizes a web browser is to view web pages on the internet,
before delving into the details of building a web-based application, it might be helpful to review the architectural model of the web, and the roles of the browser and server in that model.
the user experience
________________________________________
sharing information on the internet is a simple process of a user (or client) using a web browser such as internet explorer (ie) to request a file from a web server such as iis.
the web server sends the browser a response that contains the requested file as well as headers that contain connection information. the web browser uses the html tags in the file to properly format and display the data in the file. a web browser that displays html has the capacity to mimic any user interface.
static files compared to dynamic files
________________________________________
if the file that the web browser receives looks the same as the file that is stored on the web server, the file is considered to be static content. static content does not allow for changes based on variables like time or individual user data that is stored in a database.
the following illustration shows the transmission of a static file where the displayed date will never change.

content can be generated dynamically, either on the side of the web client (using client-side scripting, dhtml, xml, or other client applications) or on the side of the web server (using asp, asp.net, com components, isapi, or other server interfaces).
the following illustration shows the transmission of dynamically generated content where the displayed date reflects the date at the time of the request.

the role of iis
________________________________________
iis fulfills the role of the web server, responding to requests for files from web clients such as ie, and logging activity.
iis maintains information about the location of content files, what security identities have access to those files, how content files are separated into applications, and what urls are mappe


web application architecture
web sites
there is a subtle distinction between a web application and a web site. for the purpose of this paper a web application is a web site where user input (navigation through the site and data entry) effects the state of the business (beyond of course access logs and hit counters). in essence a web application uses a web site as the front end

figure 1 basic web application architecture
the information made available by a web site is typically stored, already formatted, in files. clients request files by name, and when necessary provide specific path information with the request. these files are termed pages, and represent the content of a web site.
in some situations the content of a page is not necessarily stored inside the file. it can be assembled at runtime from information stored in a database (or other information repository) and formatting instructions in a file. alternatively it can come from the output of a load-able module (cgi or isapi). the web server uses a page filter to interpret and execute the scripts in the page. web sites employing this strategy are called dynamic sites.

figure 2 dynamic web site architecture
dynamic web sites offer certain advantages to web site designers. they make it easy to keep the content fresh and synchronized with data in a database. the overall look and feel of the web site is defined by a set of pages that contain code executed by the web server during a request for this page. in this context the file can either be an plain text file with scripts interpreted by the web server, or a compiled binary file that is executed by the web server. in either case the code in the "page" references and utilizes server resources which include databases, email services, file services, etc.
a user interacts with a web site via a browser. a browser is an application that runs on a client machine, that connects to a server on a network and requests a page of information. once the page request has been fulfilled the connection terminates. the browser knows how to communicate (via http) to a web server, and how to render formatted information returned by the web server. most pages of information contain links to other pages (possibly on other servers), which the browser user may easily request. users navigate the web by clicking on links and requesting pages from web servers.
web applications
the distinction between web sites and web applications is subtle, and relies on the ability of a user to effect the state of the business logic on the server. certainly if no business logic exists on a server, the system should not be termed a web application. for those systems where the web server (or an application server that uses a web server for user input) allows business logic to be effected via web browsers, the system is considered a web application. for all but the simplest web applications the user needs to impart more than just navigational request information, typically web application users enter a varied range of input data. this data might be simple text, check box selections, or even binary and file information.
the distinction becomes even more subtle in the case of search engines, where users do enter in relatively sophisticated search criteria. search engines that are web sites, simply accept this information, use it in some form of database select statement and return the results. when the user finishes using the system there is no noticeable change in the state of the search engine (except of course in the usage logs and hit counters). this is contrasted with web applications that, for example accept on-line registration information. a web site that accepts course registration information from a user has a different state when the user finishes using the application.
the overall architecture of a web application is identical to that of a web site. it can however, become significantly more elaborate. the rest of this section will attempt to gradually build on the web site architecture to eventually reach that of a fairly complete and complex one. given the history of this industry, this classification of fairly complete may not even last by the time this paper is completed. regardless it will contain most of the concepts and components that are expected to be the cornerstones of web applications for the next several years.
pages
by far the most fundamental component of a web application is the page. browsers request pages (or conceptual pages) from servers. web servers distribute pages of information to browsers. the makeup and organization of a web pages in essence make up the user interface for the application. in web applications the browser acts as a generalized user interface container with specific user interfaces being defined by each page’s content.
in web application development environments like microsoft’s active server pages or allaire’s cold fusion, the pages are a combination of static html formatted pages, and dynamic scripted pages. the scripted pages contain code that is executed by the web server (actually it is more likely to be delegated to a scripting engine or page filter) that accesses server resources to ultimately build an html formatted page. the newly formatted page is sent back to the browser that requested it.
server scripting
it is important to note that the connection between the client and server only exists during a page request. once the request is fulfilled the connection is broken. all activity on the server (as effected by the user) occurs during the page request. this represents a very significant distinction between traditional client server applications. business logic on the server is only activated by the execution of scripts inside the pages requested by the browser.
depending upon the specific scripting engine, scripted pages can contain user defined variables, sub routines and functions. some scripting engines even permit the definition and interaction of objects.
the ultimate result of this server processing is to
1. updating the business state of the server, and
2. prepare an html formatted page (user interface) for the requesting browser.
an important and subtle part of web application design is understand and accommodating of this paradigm of client and server interaction. business objects are not always accessible when handling individual user interface requests. for example a common user interface (and business feature) in many client server applications is the automatic population of city and state fields in a us postal address when a zip code is entered. assuming that all three fields are located on the same page in a browser this feature would require an additional server page request to happen immediately after the zip code was entered. for most web applications this carries with it an unacceptable performance burden. for most web applications page requests are fulfilled in an order of seconds instead of milliseconds.


client scripting
the server is not the only component in a web application that executes scripts. the browser itself can execute scripted code in a page. when the browser executes a script, however, it does not have direct access to server resources. typically scripts running on the client augment the user interface as opposed to defining and implementing core business logic.
client scripts should not be confused with client side components such as java applets or activex controls. these components are a separate category of component in the overall web application architecture and are discussed in more detail later. the client scripts discussed here are javascript (or vbscript) code embedded in the html formatted page. the code is executed in response to browser generated events (document loaded, button pressed, etc.). with the acceptance of the new dynamic html specification, client scripts can access and control nearly every aspect of the page’s content. additionally it further opens up access to the browser object model itself, enabling client side scripts to interact with other browser resources.
when an html web page is rendered in a browser it is first parsed and divided up into elements. when dynamic html is employed each of the elements can be named or assigned an id, which could be referenced by client side scripts. some common element types include anchors (links to other pages), tables, font specifications, etc. the elements making up the content of the page have an object interface defined by the document object model (http://www.w3.org/dom/). the browser also has an accessible interface, yet differing brands of browsers may have subtle differences.
client scripts, like their server side counterparts, may contain variable declarations, sub routines and functions. the only major conceptual difference is server side scripts contained in a page are inherently procedural, while client side scripts are inherently event driven