There are a few ways of doing so – you could have an asynchronous call return an HTML fragment, for instance (done that). You could also embed placeholders in hidden HTML fragments on a page, and use a combination of jQuery’s clone/replace/append methods to push object data into them (done that too). However, there’s an even better technique available now, as a first-class citizen in the jQuery library – the .tmpl templating API.

jQuery templating is a feature that’s currently in beta (though it is distributed with jQuery as of version 1.4.3), and is based upon an existing templating plugin. I’ve had the pleasure of using the jQuery templating API for a bit of time now, and I admit that it is by far the easiest, most robust templating solution I’ve found. There are template controls for repeaters ({{each}}), conditional statements ({{if}} and {{else}}), templated HTML fragments ({{html}}), and wrapping ({{wrap}}). That’s a lot of functionality out of the box!

By far my favorite part of html templating, however, is the <script type=’text/x-jquery-tmpl’></script> tagging that you can wrap around your template fragments. One thing I’ve disliked with templating is that you have to embed potentially malformed HTML into your page – for instance, you might end up having to template id attributes. Malformed html is not the worst thing in the world, especially in hidden fields, but it certainly doesn’t help with search engine rankings and such. Having a way of clearly saying “I’m a template fragment” is a great thing, both for search engines and general maintainability.

If you haven’t gotten a chance to take a look at jQuery templating, now is certainly a great time to do so. It comes for free with jQuery, and it’s a fast, easy, and robust solution for templating needs.

ASP.NET Ajax passes the viewstate to the server and back during things like UpdatePanel updates. This is done to insure that the viewstate is always up to date, even if the page information changes during the Ajax call. Many Ajax calls, however, don’t require any changes to viewstate. Unfortunately, when the viewstate comes back, I’ve found many unpredictable results – things like page titles changing and breaks in back-button functionality in some scenarios. More importantly, these bugs are hard to track down and understand, in my experience. On top of this, viewstate is usually pretty large, which slows down ASP.NET Ajax requests and transfers more data across the wire, increasing bandwidth costs.

What have I chosen to do instead? Through Encosia, I’ve found that it’s fairly trivial to make jQuery Ajax calls into the codebehind, or even to local web services via JSON. These calls are small (they don’t send viewstate), transparent (they don’t change page information on return unless you explicitly ask to), cross-browser compatible, and rock-solid (like everything in jQuery).

Surely there are quite a few circumstances where ASP.NET Ajax beats out jQuery Ajax (for things like datagrid population, for example). From now on, though, I’ve decided that my default stance will be to write my Ajax calls in jQuery unless I can create a compelling case to do so in another technology.

Visual Studio ships with ASP.NET AJAX, which is kind of like the Microsoft bastardized attempt at a JavaScript framework. It’s been lagging behind jQuery and most other modern JavaScript frameworks since it’s introduction. Now, with full jQuery support, including intellisense, there’s little reason to have to use ASP.NET AJAX, in my opinion.

The one unfortunate aspect of official jQuery support in Visual Studio is that there are a lot of other competing frameworks, many of which are on par with jQuery, but whose market share will inevitably erode. Either way, a choice had to be made in this regard, and the right one was, in my opinion.

JavaScript can provide such a rich user experience nowadays that it rivals Flash/Air and Silverlight in many areas. It’s also getting faster (on a daily basis, seemingly), which bodes well for it’s future. If you haven’t checked out jQuery up to this point, it’s well worth a minute of your time.

This site is hosted using WordPress as the engine. What I hadn’t realized until late is that the platform actually uses a lot of these tools already. The state of these free tools allows rapid prototyping and development of websites that have extremely valuable functionality built in. This differs so much from just a few years ago, when the best tools available were tutorials and maybe a few pieces of css or javascript that would need to be largely rewritten on a per-application basis. What a great and exciting time to be a web developer!

Here is the scenario: You have an Ajax enabled .aspx page which has an UpdatePanel set to update itself based upon a timed interval from a Timer control. You also have some type of submit button on the page that does a synchronous page submission. So, what happens when you click on the submit button, and before the page submit has run through it’s logic, the timer control trips and causes an asynchronous Ajax post? Well, what I was seeing was that the page would end up in an incongruous state – the submit works, but the page updates itself to show the results of the asynchronous update, not of the synchronous submit action.

This behavior is to be expected, to tell the truth. One of the actions has to win, and it may as well be the last one into the queue instead of the first. So, the real thing we want to do is disable the timer control based upon the submit button being clicked. No problem, I thought – I’ll just disable it in the event handler for the button click, like this:

private void SomeButton_Click(object sender, EventArgs e){

Timer1.Enabled = false();

// Do stuff here…

// Maybe reenable the timer here…

}

Hmmm… that doesn’t seem to work, and here’s why. Since the submit button click is handled server-side, the enabling-disabling action won’t be propagated back to the client until the postback is complete. The timer is a client-side javascript control, so it can (and will) keep working as the page is being posted.

So, what do you do? Well, you’re only really left with one option – disable the timer control on the client side. That means you’re going to be doing it via Javascript. Luckily, I found this post that details all about using Javascript to disable the timer control. Now, all you have to do is hook up a client side event to the timer control and programatically disable it. You can re-enable it in codebehind with the button click handler, too, so you don’t have to do that on the client side. Here’s what I ended up with:

<script language=”javascript” type=”text/javascript”>
<!–
function DisableTimerControl(){

// Disable the ajax timer control before elevating on the client side.
// It will be re-enabled on the server side.
var timerControl = $find(“AjaxUpdateTimer”);

if (timerControl != null){

timerControl._stopTimer();

}
return true;

}
–>
</script>

That wasn’t so bad, was it now? The long and the short of it is that you have to be careful about using Ajax controls, but it is still pretty easy to make them do what you want if you’re on top of things. Either way, Ajax is here to stay, so get used to it!