This project is read-only.

1 Script for Every AJAX control

It's good practice (in that it promotes module design) to create a single .js file for every one of the custom AJAX controls in your web application, if it requires JavaScript. If the control doesn't need any client-side control, don't make a file. Simple.

So this means that all of the JavaScript code related to a single AJAX control should go in the one .js file you create for it. Also, only JavaScript code that contributes to that specific AJAX control should be in the file. No mixing. Or at least, do your best not to mix. There may be situations where your web application will have cross-referencing controls where one control invokes a function of another. In this case, a little mixing is OK. But remember, the main goal with keeping all your separate in its own file is to promote good module design. It's very very important.

Check out the screenshot below from the Solution Explorer view of the BingMapsSample project (available in the project's source code or the BingMapsSample download of the current release). (BTW, I'm using Jing to create all of my screenshots.)

1 Script for Every AJAX Control

Take notice that in the /js directory of the sample project I have created there is one .js file for each of the custom controls in the project that require JavaScript code (it's important to note that out of these 3 User Controls, only 2 of them, ucSearchResultsList and ucSearchResultsMap, are AJAX enabled...check out How to Decide if the AJAX Control Framework is Right For Your Project for a better explanation as to why).

If you have a TON of controls in your application that use JavaScript you're going to have a TON of files. Some folk may be turned off by this. Not me though. If you think having a lot of files is shady, consider the following perks to the best practice above:
  • It's easy to find where bugs are in your code. All you have to know is what control has the problematic functionality and you'll inherently know what file to look in for the source of the problem.
  • You'll be forcing yourself to think modular. You'll have all these files and every time you need to add a new feature you'll be asking yourself "Hmmmm. Now where should I put the code?" This is GREAT! What a beneficial exercise for us ASP.NET developers.
  • You'll be less likely to duplicate code elsewhere. This is true because you'll be thinking of the one place to put your code when there are multiple files. One place rather than many places. How delightful.

When it comes time to deploy your application to a production environment you can always create a .js.release file and centralize ALL of your JavaScript into the one file. Don't forget to run it through JSLint and Packer first!

Last edited Jun 4, 2010 at 5:02 AM by peanutbutterlou, version 6


No comments yet.