I wish I could call IE6 dead.

I’ve spent hundreds of man-hours doing CSS fixes for it, and every day, I check Google Analytics to see how close we are to its death… and every day, I’m disappointed.

Technically, it is dead. Most standards say the latest 2 versions (of course, that got really big when IE8 came out, excellent excuse to drop it), and it’s 6 years old by now, well past the average lifespan of any technology. But, the problem is, for all of my idealism and complaints and loss of efficiency, we still have over 30% of our users on the ancient mind-breaker. So, unfortunately, for all of my complaints, for all of my IE6 specific cde and CSS fixes.. it’s not dead. It’s not defined by age, but by users. So until the time comes when IE updates become mandatory, or our users finally move on… it’s still very alive, in my nightmares and in my everyday coding experiences.

More and more often, it becomes obvious to me how important an external API is. What better way is there to share your product, then to let people build on top of your service layer and customize their own interface? If someone doesn’t like the look of your program, or how it feels, they may leave; but a missed opportunity can quickly turn into another user when they find someone else’s implementation of your application. Or, other applications may pull your data into their product, giving you another revenue stream (or just more users), more popularity, your name thrown around more; it’s free advertising and a great testimony to your product that someone liked it so much that they included it in their product.

I recently looked into Flickr‘s API, for integration into a project I was working on, which spawned this thought. It is absolutely fantastic that I can call a URL with some credentials, and bam, I have the file I need. The user doesn’t have to upload (or worse, download from Flickr and reupload) to another photo-sharing application; they can just point out a url, and I can display it. It’s really awesome. Twitter has feeds, that I can pull into my blog; even my blog has an API that will allow other sites to post comments to me without ever loading my site. That’s pretty cool stuff.

For an information-hosting web app, this is one of the best things you can do to increase views and popularity. If you have a good service layer, expose some of it (with the right security, of course), let other people use your app. More users is never a bad thing.

If you haven’t delved into the realm of the .ascx, then let me briefly explain the two big benefits that have been relevant to me recently:

• Totally reusable code
• Emulate master pages; only with this, you can use the Ajax control toolkit to do it

On the first point, the reusable code point, this is the biggest. It’s the entire reason behind user controls. It lets you chunk out code that you use all over, and use it in several places; it’s a fundamental of object oriented development. Let’s do an example.

Say you have a piece of code that goes to the database and retrieves data on a member. That data is then put into a styled gridview, for the administration side of a website. But, you also have an area in a members section where a user can edit their own information (more like a formview); and, on the normal web display, casual users can browse through usernames and user roles in a paged gridview.

Don’t write the same code thrice! (or even twice!) Rather, make a user control to do all the work for you, and place it in each of your pages. This is how I’d do it:

For the sake of this article, I’m assuming you’re using a list of “Member” objects. Use whatever.

-Make a public class-level property in your control called “ReadOnly”, a bool.
-Make a public class-level method in your control called “Intialize”, which takes an IList of Member objects
-If the IList has one object, add a FormView to your control, and databind it. Otherwise, go the Gridview route (doing this all from the codebehind would keep your code cleaner and keep you from having an extra control rendered, although you could do this in the .ascx if you really wanted to; just set one to visible=”false” to the one you’re not using)
-Create all of the appropriate methods for your control for delete, update, insert, etc. and set up your formview or gridview accordingly (of course, only update for our member’s area FormView!)
-If ReadOnly is true, don’t add edit, insert, or delete buttons to your formview/gridview. (Easy enough; could set visible=”false” on the fields, or just not add them at all)

And, then, back on your three main pages, register and use your control.  Set the ReadOnly property (if it’s a bool, you should even get IntelliSense for true/false), and then on Page_Load, call Intialize on the control, passing through the IList of Members that you pulled down.

The reason we’re calling the data on the page, rather than the control, is so that the control can remain “dumb” and doesn’t need to know whether it’s a member, admin, or web display control. The less logic in the control, the better; just spit out the lowest common denominator.

Ok. Now that we’ve hit the reusable control side, let’s hit the fake-an-ajax-master-page part.

As you may or may not know, even if you wrap the ContentTemplate in a MasterPage, it still reloads every page change. This is because the MasterPage gets loaded after the rest of the page, and is treated like a control. So, if you change pages.. it loads the page, and then says afterwards, ‘oh, yeah, that was Ajax. Oh well.’

The cool thing you can do, is make one default page, and inside of that have user controls in place of your pages, something like this:

-Make your default.aspx page
-Create user controls; however, rather than logic in Page_Load of the control, put it all in a public class-level method you call Initialize.You’ll see why soon.
-Put all of your controls into your default.aspx page, with visible=”false”.
-On the onclick of your navigation buttons, run the Initialize on the control, and set it’s visible property to true, and all the others to false.. I might alternately suggest using Command and a single method rather than Onclick and seperate methods for each button, so you can pass through a CommandName, which you can then use in a switch statement and know what button you hit.

Ok. Now that we have our fancy Ajaxy page, you may be wondering: why not just visiblity? Why this Initialize thing?

This is because ASP.NET will fully render the controls, visible or not. Which means that if you have 10 pages, it will load those 10 pages and display one; which is a big performance hit on the server, especially if you’re loading database data into each of those 10. Having to explicitly call Initialize avoids this. It also allows you to pass through a common parameter to each of the controls (say, a title string that displays at the top of each control) .

Controls can certainly do much more than this; but these are the biggies for me. Have any .ascx uses of your own?

First
off: make a mockup of the design. Figure out what you want it to look
like; draw it up in Photoshop, or write up the CSS in notepad, or
however you’re doing what you do. Make a note of every bit of static
information, and every bit of dynamic information, and dump it all into
DIV tags.

Next, after the interface tier, comes the big part:
your JavaScript tier. There are three distinct parts to this, although
you may only require two.

Part 1: your object layer. If you have
things like I do (players, items, etc) you’ll want to make objects. An
example would be a player object, with player.strength, player.health,
player.level, player.name… etc. A variable for every bit of connected
information on your page.

Part 2: your update layer. Make a
library of functions for each bit of information that you update. Don’t
directly call the AJAX here; update the objects you made, or use these
as a wrapper to validate then call your AJAX functions. You’ll probably
want to include some DOM functions like:

function $(div){
return document.getElementById(div);
}

and interface updater functions like:

function updateStats(){
$(“playerStr”).innerHTML = player.str;
//etc for all other stats
}

and variable updater functions like:

function uSTR(newStr){
player.str = newStr
}
and
anything else that your page does. Try to keep everything seperated; at
a minimum, I always have a dom.js, functions.js, and then finally
AJAX.js. You’ll call your AJAX layer by using something like this:

function uSTR(){
player.str = evalAJAXPost(“playerstats.php?stat=str”);
}

Part
3: Your AJAX layer. These are the functions that use your server-side
pages. You always want to separate these because they’re things you use
over, and over, and over again. Another trick that I learned a while
ago, is that if you have simultaneous updates (e.g. sending dynamic
updates while requesting pages), make an array of AJAX objects, and
pass each page request through a different object. I’ve found that
there’s no need for more than two or three (even Gevalum only has
seven, and that’s probably overkill.) This is an excerpt from Gevalum’s
AJAXFun.js:

var ajaxes = new Array();
//if we’re FF
if(window.XMLHttpRequest){
ajaxes[0] = new XMLHttpRequest();
ajaxes[1] = new XMLHttpRequest();
ajaxes[2] = new XMLHttpRequest();
ajaxes[3] = new XMLHttpRequest();
ajaxes[4] = new XMLHttpRequest();
ajaxes[5] = new XMLHttpRequest();
ajaxes[6] = new XMLHttpRequest();
//or, if we’re IE
}else if(window.ActiveXObject){
ajaxes[0] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[1] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[2] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[3] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[4] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[5] = new ActiveXObject(“Microsoft.XMLHTTP”);
ajaxes[6] = new ActiveXObject(“Microsoft.XMLHTTP”);
}

function evalAJAXHtml(source,nr){
ajaxes[nr].open(“GET”,source,true);
ajaxes[nr].onreadystatechange = function(){
try{
if(ajaxes[nr].readyState==4){
if (ajaxes[nr].status == 200){
eval(ajaxes[nr].responseText);
}
}
}
catch(e){
//Exception-bug in FF
}
}
ajaxes[nr].send(null);
}

function evalpostAJAXHtml(source,datan,nr){
ajaxes[nr].open(“POST”,source,true);
ajaxes[nr].setRequestHeader(“Content-type”, “application/x-www-form-urlencoded”);
ajaxes[nr].setRequestHeader(“Content-length”, datan.length);
ajaxes[nr].setRequestHeader(“Connection”, “close”);
ajaxes[nr].onreadystatechange = function(){
try{
if(ajaxes[nr].readyState==4){
if (ajaxes[nr].status == 200){
eval(ajaxes[nr].responseText);
}
}
}
catch(e){
//Exception-bug in FF
}
}
ajaxes[nr].send(datan);
}

Now,
for the server-side part of this AJAX tiered application. There are a
thousand ways to do this, depending on personal taste; I choose PHP,
since it’s lightweight. You could use ruby, or asp, or asp.net, or
anything that outputs text. All I have to do is pull the information I
need, and write out my JavaScript updater function, and I’m done.

You
may be asking: why bother? Well, the easiest is that it’s the absolute
fastest way to get information securely from a database to the client.
It sends the minimum information possible, and so saves you bandwidth.
It’s invaluable for a little hosted server, or if you’re hosting
yourself and can’t afford a business-class internet line. Not to
mention, it’s faster on the user’s end, so they wait less, making them
less likely to turn away from some lag-o-licious old monolith of a
website. It’s streamlined, it’s dynamic; what else could you ask for?