ASP.NET Web Forms is a great paradigm in my view, but it has a lot to answer for. One of the main things it encourages is Windows Forms developers to come to the dark side of web application development. Web application development is totally unlike Windows Forms, but with a drag and drop RAD environment, and an event-driven model, Web Forms hides a lot of basic HTTP plumbing from the uninformed. And what happens is that things don't work as they expect. This question is typical of a large number of similar ones I have seen, and in fact finally prompted this write-up.
To start with, here's an overview of how web applications work. Consider a restaurant. You walk in, are greeted by the maitre d' and get seated. You give the waiter your order and he disappears. A while later, he returns with your meal. You don't know where your meal came from or how it was prepared. You don't care, so long as it is edible.
While he was gone, and completely out of your sight, the waiter passed your food order to the chef in the kitchen. The chef sprang into action and prepared the order. A part of the order may have been fulfilled without any real work, such as a plain bread roll. Or the order may have needed special processing, such as frying or grilling. These tasks would have been passed to specialists within the kitchen to manage. Once complete, the order is passed it to the waiter for delivery. The chef doesn't know what happened to the food that was prepared or where it went. He doesn't care (so long as he receives no complaints).
Web applications are like this. For the diner, read client. The chef is the web server, and the waiter is the transport mechanism for the Request (the meal order) and the Response (the cooked meal). The client makes a request which TCP conveys to the correct web server, given the URL of the request. The server examines the request and decides if it can be fulfilled without further ado, or whether some processing is required. The part of the request which is examined primarily is the file extension. These may have been registered with the server and mapped to special processors, such as ASP.NET or PHP. Or, in the case of an image or html file, there is no need for processing. The raw content of the file is served as a response.
A palatable meal in the case of a web response is generally html. If the processors are called into play, instead of grilling or frying the ingredients in preparation for the response, they execute any related or embedded code logic, which is responsible for generating html dynamically. However, once the response has been sent, the web server doesn't know what happened to it or care. Like the waiter, it sits back on its chair, and waits for the next request. It has no persistent connection with the client.
Where Javascript Fits In
Javascript, when associated with ASP.NET (or any other server-side technology) generated web pages is a client-side scripting technology. It means nothing whatsoever to the web server. Browsers contain Javascript interpreters, which are responsible for executing javascript code. Javascript code can only be run within the context of the browser, and in this context, it runs as a result of events that take place when the user interacts with the web page in the browser. This fact is important. It means that if no events take place, Javascript is nothing more than embedded strings of text within the page. What is also important to understand is that it is only the user who can cause events within the page to fire. The web server cannot. It has sent the page to the user, and gone back to its chair to wait for the next request.
The extent to which Javascript can perform its magic is confined by its security model. By default, Javascript is confined to a relatively benign set of actions. It can manipulate the DOM of the current page (the root of DHTML), respond to events that take place within the current page, open new browser windows and fiddle with a limited number of settings within the browser, such as invoking the Print dialogue box. Using xmlhttprequest, it can also make additional web requests for content hosted in the same domain as the page the script is running within (AJAX).
What you can't do as a web developer
Hopefully by now it should be clear that html itself is totally inert. Javascript has only very limited privileges. Once the response has been sent by the web server, the server might as well disappear in a puff of smoke as far as the current page is concerned. This means that there are a lot of things that web developers would like to do that are impossible. While not comprehensive, the following list of things that cannot be done represents those which are the most commonly asked in the forums at www.asp.net:
- Force a page to print without invoking the Print dialogue box
- Select a printer
- Bookmark a site
- Remove an item from the browser's History
- Remove an item from the brower cache
- Read cookies set by other sites
- Access the client's file system
- Force a user to upload a file
- Get the size of a file prior to upload
- Get the dimensions of an image prior to upload
- Determine the file type prior to upload
- Access a database on the client machine or the web server
- Invoke Word, Excel, Outlook etc
- Force the user to download a file or plugin without a prompt
- Get the filepath of an upload
- Adjust their page margins for printing
- Change their default printer
- Disable the back/forward buttons
- Read a key from their registry
- Change their security settings
- Automatically run an EXE on the client
- Force them to enable cookies
- Force them to enable javascript
- Access a page on another site
So how can you perform these actions if the business requirements demand them? There are a number of options. Traditionally, developers created ActiveX controls that the user must agree to download and install. More information can be found here, but they are limited in that they can only work with Internet Explorer. This is usually all that's needed for corporate Intranet sites, although if IT security teams forbid the installation of plugins or ActiveX, you have a problem.
A second option is to use Flash or SilverLight. Like ActiveX controls, these technologies can be granted specific permissions to access the local file system as well as network locations. However, unlike ActiveX controls, they are not restricted to the Internet Explorer browser as a host. There are plugins for a number of different browsers for both types of application. A final option is to simply create an exe that the user chooses to download and install like any other application.
