I found this excellent document on the msdn site. Not only can I fully agree with the content, the document is also built up well and provides a good introduction on how a maintainable and scalable dataAccess layer could be built in .Net http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/CustEntCls.asp

Today I wanted to check the contents viewstate of a page I was debugging.

I found a handy parser for this on the site of Paul Wilson.  It's web based, so very handy to use.
http://wilsondotnet.com/Demos/ViewState.aspx

 

A javascript file, which you can reference in the html of your web pages, is typically a .js file residing somewhere on a server that is being served by the webserver to the browser of your web app's user.
Javascript files are good for your application's performance because the are cached on the client, therefore avoiding that the content would have to be downloaded between to your pc on every page request.
Compared to inline script, this can make your application quite a bit faster.

Sometimes, when doing performance optimization of a script-intensive application, this is way of working is worth further optimisation:
- you definitely want to document your JS code with some inline comments (especially if you a lot, complex code).  But these comments are also being streamed to the browser, and take up bandwidth.  This may sometimes force you to cut down on the comments (not what you want).
- you want to use indendation to make your js code more readable -> again bandwith lost!

The solution to this, is to create a generated js file (e.g. as an aspx page).
Instead of creating a js file, you let the script code be rendered by some serverside technology (I use ASP.Net, but it could also be jsp, php, etc).
This gives you the best of both worlds:
- your file is cached on the client
- comments can be written in serverside code
- you can optimize the jS by elimitating all blanks, tabs, etc that are not really necessary
I did some performance testing, and my scripts were some 30 to 50% smaller !
This is worth the effort if you have enough scripts!

Another added value: you can determine what code to render and what not. E.G based on the user's browser, security rights, etc

One issue though: your code becomes less readable and is a bit more difficult to maintain.
Therefore we develop the code as a js, and convert it to an ASPX just before deploying the application.

It would be nice to have some tooling to do this conversion, but currently we haven't got that yet.  What we do have is a baseclass for these scripts.  The baseclass is responsible for removing the spaces, tabs, etc and ensure that all the scripts are coded in a consistent way.
This facilitates "generation" later on if we some spare time to build an automated tool.

Robby

Microsoft is currently developing a powertoy for Internet Explorer that is able to trace and monitor http trafic.  If even allows you to "fiddle" with the http requests and responses when you're tracing.  Hence the name "Fiddler".

A first article on MSDN describes the overall in and out of the tool.

http://msdn.microsoft.com/ie/default.aspx?pull=/library/en-us/dnwebgen/html/IE_IntroFiddler.asp

I did some initial tests with the tool and they are promising, though there are still some improvements to make (logical considering it's only V0.98)

Nevertheless, I'm glad to see MS developing this kind of tooling (hope it stays free though).

Robby