Versions Compared

Old Version 1

changes.mady.by.user reinhard reinhard

Saved on

compared with

New Version Current

changes.mady.by.user reinhard reinhard

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

A major challenge in web-programming on the bare metal (i.e. without ASP.NET or a similar framework) is that the web was not intended to be an application platform. The web was constructed more like a file system for the global distribution of "content" (text and images). You give your browser an URL, the browser gets you the file behind that URL. The server actually delivering a page forgets you and your browser immediately after the transmission. The following two characteristics of this simple technology facilitated the tremendous success of the web:

  • URLs are supposed to uniquely identify a particular page (or other file) on the entire web (or, by extension, an intranet).
  • The web is stateless, i.e. the serving computer can't remember anything for you. This keeps things simple and scalable.

What's good for serving content is bad for programming applications, however:

  • URLs are a lousy medium for telling an application what to do next.
  • An application server not remembering anything is usually not very useful.

As clever programmers figured out quickly in the 1990s, you CAN build web-applications on top of the infrastructure that browsers and HTTP give you, it is just much harder than
building a regular application that runs locally on a computer or as client-server. The problem is that the web as application platform does not lend itself well to the style of programming developers of GUI-applications have invented and refined over the previous two decades – based on objects within objects, events and event-handlers.

...

Here is an annotated diagram to illustrate the concept of HTML-generation (the "rendering") by an .aspx and .aspx.cs-program:

  • As we see in the picture, the browser is showing an .aspx page named a.aspx. What you can't see is that the HTML the user has in her browser has been generated by that a.aspx page and its associated code-behind in a.apsx.cs, because that has happened in the recent past. The diagram begins with the user clicking on the link for another .aspx page – b.aspx.
  • The browser sends the request for b.aspx to the web-server.
  • The web-server executes b.aspx, or, the code-behind in b.aspx.cs, what renders the page.
  • The rendered page (i.e. a mix of HTML and, most likely, javascript) is sent to the browser.
  • The browser displays the HTML (and javascript) for b.aspx.

Things are not quite as simple when a user manipulates a control element. In this case, the browser sends additional information about the contents of the page and its controls (view state) and the manipulated control. The latter is used by ASP.NET to raise a corresponding event that can be handled by a method (event handler) provided by the application developer. For example, when a user fills in a form and clicks the submit button, the filled-in values are sent to the server along with the information that the submit button has been clicked; ASP.NET then calls the event handler that is associated with the button (e.g. SubmitButton_Click in TestForm.aspx.cs). The form information is put into the ViewState object so that the event handler (and other server-side code) can access it and store it in a database, for example.
In addition the view state, which makes client-side information available on the server (and allows the server to control the state of web controls at the time of rendering), ASP.NET provides "session state" that stores information associated with an ongoing interaction between browser and web server on the server, so that the server can follow up on a conversation with a particular client when it sends another page request. The following section elaborates on session state.
To make the illusion of programming a regular client-server application complete, ASP.NET provides several means of storing an application's "session" state (its "variables") from page
request to page request, but they fall into two categories:

  • the data is stored in the web-browser
  • the data is stored on the web-server

In order to discuss these options more verbosely, let's look at what a web-application has to remember actually.

...

Independently from the medium of storage, the key ideas are always the same:

  • send all the session data back and forth between browser and server (scales well, takes bandwidth and extra effort to encode and decode the data)
  • send only a reference to the data back and forth between browser and server (takes very little bandwidth and effort, but you give up the advantages of statelessness)

re-call, re-motion's web execution engine, inherits from ASP.NET the ability to store state information in a database, a state-server, in the process (i.e. in memory) or in the browser itself. In practice, even a mix of these methods can be used.

...

The beauty of this scheme is that the code to render the form and all the code to handle data entered into the form are wrapped up into one neat package (a page object, that is). However, here we face a problem: What if we want to render a different page in response to a request? We already know that by rendering links, the client can navigate from one page to another by clicking the link, but what if the server-side code determines that another page should get control of the request and handle it? Two techniques exist, named after their corresponding API-calls:

  • Response.Redirect
  • Server.Transfer

To see how each of them works, let's use a detail from another web-site – entering personal data when registering at a dating web-site. We use two pages, boringly called first.aspx and next.aspx.

  • first.aspx is a form for entering a nickname, gender, sign of zodiac and age
  • next.aspx is the next form, asking for favorite pastimes, so that the web-site can match-make the user with other users with overlapping interests.

For this web-site to work, the server must cause a transition from first.aspx to next.aspx as soon as the user has submit first.aspx (and the input could be validated). Just as the name suggests, Response.Redirect achieves this by sending the browser a redirection response, telling it to request the desired page – a fairly conventional technique most web-programmers know.

Server.Transfer is more sophisticated: The server pretends that the next page (i.e. the desired page) is the same as the one before, just as in our search-engine example. In reality, however, not the code-behind for the page is run to re-render the page. It's the code-behind for the next page that is run. Here are two diagrams to illustrate the concepts – one for Response.Redirect and one for Server.Transfer.

  • The user (in this case the author) has entered his first installment of personal data and lied about his age (of course!) He clicks the Submit button to post that data to the first.aspx page/program.
  • The data is posted.
  • first.aspx executes, or better: the event-handler for the Submit-button. This event-handler finds this data to be in good working condition and therefore initiates the display of the next.aspx page by executing a Response.Redirect to next.aspx.
  • The redirect is solicited from the browser with a 301 http-packet (wikipedia)
  • The browser does as told by the server and requests next.aspx
  • The server merrily obliges (after all, he came on to the browser first) and runs next.aspx, just as if it was the browser's original idea. next.aspx executes, thus rendering the pastime-page for the author's browser.
  • The author finds the newly rendered next.aspx form.

  • The author has entered his first installment of personal data and lied about his age (again!)
  • The data is posted.
  • first.aspx executes, or better: the event-handler for the Submit-button. This event-handler finds this data to be in good working condition and therefore initiates the display of the next.aspx page by executing a Server.Transfer.
  • next.aspx is executed on the server, rendering the html for the next.aspx page.
  • The rendered page is sent to the browser.

Note that the URL displayed in the browser still is http://first.aspx. This is not a mistake by the author who drew the picture. The browser did a postback to first.aspx and thinks it got back the rendition of first.aspx's code-behind. The browser cannot know that, meanwhile, the server has sneaked the execution of another page into the browser's request.
Compared to Response.Redirect, Server.Transfer has one big advantage and one disadvantage. The advantage is that it takes one round-trip less for the transition to the next page; the disadvantage is that an URL does not uniquely identify a particular page. The disadvantage might look minor to you, but often the "U" in "URL" - having a unique identification for a page - is more important than performance. In its pure form, the URL is required to specify even which domain object(s) is/are displayed in the browser, so that the server can completely reconstruct what is seen in the browser from the URL alone. re-motion supports this behavior, but not by default.