When you’re developing client-side applications, a problem you’ll almost inevitably have to deal with is how to work with services that reside outside your website’s domain. Though many modern APIs do support JSONP, which is a clever workaround to somewhat mitigate the cross-domain problem, JSONP has its own problems.

Worse, if you encounter an API with no JSONP support, the cross-domain barrier can quickly become a formidable one. CORS is slowly becoming a viable alternative, but it requires that the remote service support it via special HTTP headers and browser support for CORS is still not ubiquitous.

Until CORS is more broadly supported, an alternative solution is to bounce cross-domain requests through the web server that hosts your website. In ASP.NET, the best tool for implementing that sort of middleman endpoint is the HttpHandler.

In this post, I’ll show you how to create an HttpHandler to service cross-domain requests, how to use jQuery to communicate with the handler, and an example of one improvement that this approach makes possible.

Click here to read the rest of this post »

They aren’t the most glamorous projects, but thousands of developers have integrated my Highslide JS .NET and PostBack Ritalin controls into their sites and applications over the years. PostBack Ritalin was even included in Subtext at one point. It’s definitely a great feeling to see your work put to good use (in fact, this motivator can be even more powerful than monetary gain).

As jQuery has risen in popularity among the ASP.NET community, both controls seem somewhat superfluous to me, yet they have surprisingly remained very much in-demand. As long as people are using them, keeping them working and bug-free(ish) is something that I’ll continue to pursue.

I wouldn’t mind some help though.

Over the years, I didn’t keep the source code for these controls closed due to any illusions of ever turning them into commercial products. Rather, they were the first server controls I had built for general consumption and the quality of their code is not great. For the same sort of reasons that developers “go dark”, I always preferred to keep that code hidden in my junk drawer.

At this point though, keeping their source hidden just to protect my delicate programmer-pride is counterproductive, so I’ve open-sourced both controls on GitHub. Go forth and fork them – pull requests are welcomed.

Fork PostBackRitalin on GitHub

Fork Highslide JS .NET on GitHub

A reader contacted me this weekend to inform me that jQuery 1.6.2 had broken all of my old examples of using jQuery with ASP.NET services. Not good! How could such a simple update have caused this?!

I didn’t really expect that updating from jQuery 1.6.1 to 1.6.2 would break anything, much less break everything.

As it turns out, the problem didn’t have anything to do with jQuery 1.6.2 or my own code. However, while investigating, I ended up falling prey to the same treachery that led to the original bug report.

Click here to read the rest of this post »

Mea culpa: I may owe your fingers an apology.

If you’ve been using my approach for directly calling ASP.NET’s JSON-based services with jQuery, you know that specifying the correct Content-Type on your requests to them is a crucial part of coaxing JSON out of them. However, when I suggested that a Content-Type of application/json; charset=utf-8 was necessary, that was overly specific.

Click here to read the rest of this post »

With the confusion surrounding jQuery 1.6′s changes to .attr() and the addition of .prop(), one of my favorite new features nearly slipped under the radar. The feature I’m referring to is that $.map() now works against plain JavaScript objects in addition to arrays.

$.map() has always been a useful utility method, somewhat mimicking ECMAScript 5′s native Array.map() method. If you’ve been working with JavaScript long, you’re probably already comfortable with passing anonymous function callbacks around anyway, which makes higher order functions like map an intuitive way to write concise, expressive transformation code.

With jQuery 1.6, now you can use the same approach when working with regular JavaScript objects. There are a variety of uses for this, but I want to focus on one real-world usage in this post: extracting an array of the keys contained within a JavaScript object.

Click here to read the rest of this post »

I’ve been considering a change in the permalink structure for my posts for some time now. The /yyyy/mm/dd/post-name/ structure I started with is certainly nicer than what WordPress defaults to, but a problem with those dated URLs has emerged over the past few years: link ageism.

Link ageism is what I’ve begun calling the tendency most of us have to avoid URLs that indicate links to older content. With the year of publication front and center, my old URL structure was particularly susceptible to link ageism. When I began hearing from new readers who almost skipped over my still-relevant content just because the URL looked old, the dated URLs had to go.

Along with the obvious problem of redirecting old URLs to new, I ran into another issue that I hadn’t given much consideration before the change. The new URL scheme caused the counters on my Twitter and Delicious sharing widgets to reset to zero on all my existing posts.

Luckily, I was able to find a solution to the sharing counter problem, and I thought that workaround might be useful to others. What I’ll describe is specific to WordPress and the particular URL change that I made, but the same approach could be applied to save social sharing counters when changing URLs on most any publishing platform.

Click here to read the rest of this post »

Years ago, Joe Stagner was one of the first people at Microsoft that I happened to get in touch with about ASP.NET and the topics I was blogging about here. In fact, he was responsible for the first real bump in traffic my blog received back in 2007. So, when Joe asked me to come on his podcast earlier this year, I was eager.

We talked about a wide variety of topics, including dealing with plagiarism, how to become a Microsoft MVP, and selling new web technology to non-technical decision makers. Fair warning: it was unscripted and less jQuery, ASP.NET, or JavaScript themed than other podcasts you may have heard me on in the past, but I think it turned out pretty well if you’re interested in broader topics surrounding the technology.

You can download or listen to it here on Joe’s site: Podcast – Dave Ward Encosia

If you’ve spent much time working with the .NET platform, ASP.NET’s simple, convention-based approach to exposing JSON endpoints seems just about too good to be true. After years of fiddling with manual settings in XML configuration files, it’s understandable to assume that working with JSON in ASP.NET would require a similar rigmarole, yet it does not.

Unfortunately, this unexpected ease-of-use isn’t obvious if you don’t already know about it, which has led some developers to build needlessly complicated solutions to problems that don’t actually exist. In this post, I want to point out a few ways not to approach JSON in ASP.NET and then show you a couple examples of leveraging the frame work to do it “right”.

Click here to read the rest of this post »

If you’ve been working with JavaScript very long, you probably know that you should format curly braces in JavaScript code a certain way. In fact, if you’ve watched my TekPub series, Mastering jQuery, you’ve heard me stop James and remind him that at the beginning of nearly every episode.

However, you’re less likely to have seen a clear example of why this matters or why you should care. Even when you hear advice from a trusted source, it can be difficult to heed that advice if it seems like hearsay or convention for the sake of convention.

While I was working on my recent post about extracting data objects from HTML structures, it occurred to me that some of its example code presented a great learning opportunity regarding this topic. So, I want to take advantage of that opportunity to show you a concrete example of how placing your braces on the wrong line can break your JavaScript code.

Click here to read the rest of this post »

I was talking JavaScript with Scott Hanselman recently, discussing different approaches to client-side development and the complications that surround them. Part way through, he decided that we, along with Elijah Manor, should sit down and make a podcast out of it.

So, we did.

It was just a touch nerve wracking to sit down and record with no agenda, firm topic, or preparation, but Scott’s a pro and guided us smoothly through. Within an hour of him saying “let’s record a podcast,” he had pulled recording equipment and a quiet room out of thin air, and we were finished.

If you’re a regular reader here, the discussion may be below your level of expertise, but it potentially good for sharing with colleagues who aren’t yet at your level on the client-side.

You can listen to it here: <JavaScript and jQuery: Moving beyond Alert() />

Also be sure to check out Elijah’s summary of what we talked about, which includes links to most of the resources we discussed: Hanselminutes #256: JavaScript & jQuery: Moving beyond Alert()