iMadalina on .Life

Linkul prin care am gasit toata tarasenia:

http://itboard.ro/CS/blogs/zolis_tool/archive/2006/10/25/_2200_Sa-moara-Microsoft_2200_.aspx#comments

Si urmatoarele:

http://vladimir.metromind.ro/business/despre-load/

http://dragosh.bloghost.ro/2006/10/25/concurenta-si-propaganda/

MSDN Magazine, Nov 2006

Here is the scenario: in an aspx page you have a link of a file (adobe, word, ...) and you want the user to download the file, with the options: Open/Save. The code for getting that is:

Response.Clear();
Response.AddHeader("Content-Disposition", "attachment; filename=" + [file].FileName);
Response.ContentType = [file].ContentType;
Response.OutputStream.Write([file].FileByte, 0, Convert.ToInt32([file].Dimension));
Response.End();

The code triggers the Open/Save dialog to appear (the 'attachment' option does that). But if the user wants to open the file, it is opened in the current window. You would like it to be displayed in a new browser window.

If you click the 'Open' option for a Word file, Word application will open and the file along with it. But if you open a pdf, the Adobe Reader has a plug-in for browsers that allows for the file to be opened directly in the browser.

So, for all the file types that can be opened directly in the browser (pdf, jpeg etc) what do you do? The first idea is to let the file link be an input button that triggers JavaScript code that opens the new window. And let that new window display the aspx file that in the PageLoad event has the above code. Ok. Done. We have now solved the issue of opening the pdf file in a new window. But we are left with the issues:

• if the user selects "Save as", after the file is saved to disk, the new browser window remains opened
• if the file is Word and the user selects "Open", a new instance of the Word application appers, and the new browser window remains opened (and, of course, empty)

So while solving the one 'Open' pdf issue, we triggered other several ones. What is to be done? Different actions for different file types? No.

The next idea that comes into our minds is to close the empty window through JavaScript:

Page.RegisterClientScriptBlock("key", "[script] window.close [/script ] ")

Surprisingly, the code does not work. The window remains opened. If you select View Source for it, there is no code there from your page. No headers, no JavaScript. Why? Because you have Response.End() in the code. If you choose to not use this line of code, the files may end up being corrupted.

So what is the answer? It is simple yet not easy to be found - because you always have in mind the premise that the user must have the option of Opening/Saving the file. The answer is:

Response.AddHeader("Content-Disposition", "inline; filename=" + [file].NewFileName);

How come? Well, if you select Inline, the applicatiopn will try to write the file directly to the browser. If the browser has a plugin for that type of file (for ex PDFs) the file will be opened in the new window. (Y) If the user wants to save it, the plugin has a menu bar and options for saving on disk. If the browser does not have a plugin for the file, the Open Save dialog will appear and upon any choice the new empty window will be automatically closed.

Since I have searched for this topic on the net a long time before I managed to get it right, here are some keywords for finding this post: Response.End, window.close(), Open File, new browser window, Adobe Reader, pdf.

As we all know, on Web Farms we cannot maintain Application State and Session State in process, because ASP .NET does not provide a mechanism for sharing session information across IIS applications, which, as unfortunate as it may be, has to be dealt with. The most common solution is to store session state ot of process, that is in SQL Server.

Yet, another option does exist. A Web Farm has a Load Balancer - a hardware or software module that receives all the requests sent to a Web Farm and decides which server of the farm to send them to. this Load Balancer supports an option called client affinity or sticky session. If enabled, it means that once a load balancer sends a request from a client to a server, then all the next request from the same client will be sent to the same server. This way, state variable can be kept in process.

The downsides to this solution do exist and they are:

• some servers may get busier than others at certain points in time
• if a server that a client is "stuck" on goes down, it takes the state variables with it. When the load balancer will send the next request of that client to another server that is available, the user's information will not be found any more.

In conclusion, depending on the application requirements and solution implementation, this is an option to be considered.

The best example that I can think of for the next scenario is a login page for a web application - it is very useful for this kind of page to have auto-focus on the UserName textbox. How is that focus achieved? There are 2 ways:

1. write a JavaScript line of code in the aspx file
2. use the Control.Focus() function. If you are using a Login web control, then Focus() on that control will do the job and the cursor will be blinking in the UserName textbox of that control when the page is displayed.

What you may not know is that what the Focus() function actually does is to add a JavaScript line of code in the aspx file on runtime, line of code that, when interpreted, renders the focus effect.