Additional Info

Recent Comments

Joseph Casey 5/27/2015 3:17 PM
In response to ASP.NET MVC 5 with EF 6 - Working With Files
Probably should have read the title. Couldn't use it with Visual Studios 2013. =[...

jean 5/27/2015 8:41 AM
In response to iTextSharp - Drawing shapes and Graphics
hey Mike, I read your arcticle about drawing on PDF with ITextSharp, it was really interesting !...

Alexandros L 5/26/2015 10:50 PM
In response to Entity Framework 6 Recipe - Hierarchical Data Management
You are a live saver.. thank you so much......

saurabh rao 5/26/2015 1:03 PM
In response to ASP.NET MVC 5 with EF 6 - Working With Files
Hey Mike ! Great article ...the code worked flawlessly for me. Didn't have any issues executing it ....

Vijay 5/25/2015 2:12 PM
In response to How To Send Email In ASP.NET MVC
Thanks...

RR 5/25/2015 8:58 AM
In response to Web Pages - Efficient Paging Without The WebGrid
@MIke.. is it possible to combine pagination and filter (change category ) in the script? Thanks...

Irfan Khan 5/25/2015 6:19 AM
In response to Highlighting Keywords Found In Search Results
This is truely helpful. Thank you for the brilliant tip....

Manoj Kulkarni 5/25/2015 4:46 AM
In response to Custom TagHelpers in ASP.NET MVC 6
Thank you for nice article. Really helpful....

Sean 5/21/2015 4:20 AM
In response to ASP.NET MVC 5 with EF 6 - Working With Files
Thank you for the tutorial. Saving to the database works, but the save FilePath is not working. It...

KrASh 5/19/2015 11:10 PM
In response to Adding Search
Hello Mike, I have a question about the second search. In one line it has a where with the title and...

Share

What ASP.NET Can And Cannot Do

If you are new to web development and choose ASP.NET Web Forms as your starting point, you may be forgiven for not understanding how ASP.NET works, and what its role is. This article covers the basics which should help you discover your limits.

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.

Date Posted:
Last Updated:
Posted by:
Total Views to date: 50828

3 Comments

- anoynmous

correct this ""ass well as network locations"" in the last paragraph -s in ass :-) . by the way your style of writing is good. keep is up

- Jack

Great article, its like seeing the real picture. Good one. POst more article.

- Polyt

Very True indeed, You must create a book