I’m currently working on a web application and am trying to take advantage of the ASP.NET AJAX framework (which I think is kinda weak is comparison to some other frameworks, but I digress).

I was attempting to use the modal pop-up control, but the framework is apparently manipulating a node in the DOM before it has been closed. If you check out Microsoft’s support page, you’ll notice that they don’t have any real solutions - only workarounds. Lame.

Unfortunately, none of these workarounds are feasible given the current environment in which I’m working so I’m having to essentially create my own modal pop-up. If you’ve got experience with this issue and have come up with a solution (versus a work-around), please leave a comment.

Edit June 5, 2008: Commenter tbela99 suggested verifying that all of your existing XHTML is well-formed (with no closing tags). This is always a step that should be done prior to releasing; however, it’s a difficult thing to do whenever you’re adding functionality to a project that has already been released. tbela99 made a couple of additional suggestions that are more JavaScript oriented, as well - check out the comments.

Recently, I’ve been working on a project that will ultimately require new users of the system to create their accounts with stronger passwords than the application has typically allowed. Existing users will be required to update their accounts with stricter passwords. The software is a distributed web application, and the code that I am working is a the application layer.

I’ve used a couple of design patterns to essentially build a framework that allows us to setup a password object and add and remove policies to it at runtime via XML flags. Policies are nothing more than rules that will evaluate the password against a single requirement, such as its length or whether or not it contains a specified number of digits and/or symbols. For every policy that the password is evaluated against, the framework will generate a set of error messages as well as a password strength rating and will return them once the rating process has completed.

Ultimately, this will all be bound to the front-end when the overall project is completed; however, for now, there’s no UI against which to test the framework’s performance. Since testing is arguably one of the most important phases of software development and since there’s no true UI to provide any level of feedback from this framework, I chose to take a true test-driven development approach to the password and its policies.

Write Test Cases First
Because we designed the software upfront, we new how the system should behave before we actually began building it. This made it relatively easy to write test cases first - we new what our inputs were going to be and we new exactly what outputs to expect for each case. After writing these cases, I found myself to be more conscientious of the code I was writing for the actual system.

Although it’s wrong, it’s not uncommon for developers to first build their application and then right the test cases (numerous articles are available online about this). This is incorrect for a number reasons primarily because you’re basically writing tests for a system you’ve already built - in the same way that writing code after the test cases made me more aware of what I was writing, writing your test cases after building the components will likely result in writing cases that fit the existing system. This completely misses the mark on the purpose of Test Driven Development. Writing test cases to fit the software is backwards - write your software to fit your test cases.

How long did it take?
This took a little bit longer to do for several reasons. First off, writing a test suite to cover branches, statements, outputs, etc. of your system adds to the amount of time to complete the project (or phase of the project). Couple that with updating various components and then developing new test cases for those changes, you’ve got a pretty full plate of things to maintain. Ultimately, it may result in a slightly longer period of time to complete, but if this is taken to account in project planning it shouldn’t be that big of a deal. Additionally, you’re only increasing the quality of the software, so I’d argue that it’s worth it more often than not.

Combinations and Permutations of Policies
This was the fun part. Initially, we started off with a small set of policies; however, as the project matured and we gathered more input, we had to create additional policies. This resulting in us testing possible error messages as well as the various strength ratings for each arrangement of the policies. It’s really not that big of a deal if you’ve got a couple of people working on the project, but it’s easy to see how fast something can increase in complexity by simply introducing one or two more components.

Overall Impressions
Building this framework using Test-Driven Development was great. It prevented the project and it’s various combinations of outputs from getting away from us very early in development. It also resulted in a great feedback of a system that doesn’t have an interface with which to interact. Finally, it generated a strong sense of software quality once the system was developed and all of the test cases passed.

Maybe I’ll revisit this project to show off the interface once we’ve finished it, but that’s not really something I’m planning to focus on showcasing. We’ll see.

That’s it for now,
Tom

Recently, I’ve been working on some client-side code for a web application that needed to encode some data prior to invoking an AJAX request, and then needed to decode the response data upon receiving a successful response; however, I discovered a nuance in JavaScript’s replace() function that required a little bit of extra work to get it operator with the degree of flexibility that I wanted.

Because ampersands are usually used to delimit query string parameters, the server wasn’t handling the submitted data correctly. To mitigate this issue, the ampersand character needed to be encoded. We stored the encoded representation of the ampersand in a local variable [creatively] called _ampersand.Next, we wrote a function that takes in the data to be sent across the wire, encodes the characters, and does some additional processing, before returning the encoded data:

function encodedData(strInput) {

return strInput.replace(/&/g, _ampersand);

}

It worked fine; however, the replace() function proved to require a little additional work for it to decode the data correctly. Since we needed to do a global replacement of the ampersand token, we were using the g operator, but inserting a variable into the replace() function does not work. Actions speak louder than works, so here’s what I mean:

// this does not work…
function restoreAmpersands(strInput) {

return strInput.replace(”/” + _ampersand + “/g”, “&”);

}

At first, it seems as if it work work fine - concatenate /’s on the value stored in _ampersand and then let JavaScript get to it. Unfortunately, this isn’t how it works. One solution would be to simply hardcode the value of the _ampersand variable into the replace() function, but that’s poor coding. The solution I ended up using is actually extremely simple and it makes perfect sense.

Because replace() requires a regular expression to work its magic, giving it a concatenated string literal will not work. Instead, I ended up first creating a regular expression that includes the _ampersand variable and the global operator, then I passed it into the replace() function. Have a look:

var sRegExInput = new RegExp(_ampersand, “g”);
return strInput.replace(sRegExInput, “&”);

Extremely simple solution to a problem that, in my opinion, shouldn’t have been much of an issue at all. Oh well, at least I know that I wasn’t alone.

I’ve been working on a small JavaScript library that is built using Prototype, and discovered a small quirk that caused Opera and Safari to respond differently than IE and Firefox when using the dom:loaded event with the document.observe function.

According to the Prototype documentation dom:loaded will “fire immediately after the HTML document is fully loaded, but before images on the page are fully loaded.” My script manipulates a set of images that are on the page, and I needed to process each image before the page loaded. If I waited until the document had fully loaded, then a flicker would occur in a couple of browsers. Unfortunately, it wasn’t happening in every browser so this made it difficult to diagnose.

Initially, my approach was to first intercept the images, hide them (save for the first image), and instantiate my object all before the DOM had finished actually loading the images. This is basically what I was doing:

document.observe(’dom:loaded’, function() {

// error checking, reading images into an array here
images.each(function(i) {

if(i != images.first()) {

i.hide();

}

});

// apply some specific margin styles here

});

The end result worked well - it behaved exactly as I had anticipated across IE6, IE7, Safari, Opera, and Firefox but the problem didn’t occur until I uploaded everything to a web server and began running tests across these same browsers. That’s when I found an ugly bug: Opera appeared to be completely ignoring all of the initial processing. Safari occasionally demonstrated the same exact error, but it was inconsistent - sometimes it worked, sometimes it didn’t.

Rather than try to hack the code to get it to bend just enough for Opera, I wanted to investigate it and figure out exactly what was going wrong. Sadly, Opera doesn’t have a nice DOM debugging console (at least not that I found), so I had to resort to creating some test cases to pinpoint the issue.

First, the reason that the error didn’t show its face until the script was running on a web server is because the images were stored locally so there was close to no time required for the images to load - on a web server, that’s obviously different.

Secondly, regarding the script, I’m not 100% positive that this is the problem, but it’s as close as I could come based on the results of my tests. What I found is this:

Earlier, I mentioned that the dom:loaded event is triggered prior to when the images are loaded, right? Well, I was initially trying to access the image.height property during this processing. Whereas the other browsers were already parsing each image’s properties, Opera was not. From what I gather, the other browsers are loading up the properties of each image prior to actually displaying them, and Opera is delaying all of this until the dom:loaded event has completed. Basically, this makes it impossible to process any of the images until they are visible on the screen.

After discovering this, I made some changes to the code. I was somewhat reluctant to do this at first because I didn’t wanna sacrifice some of the slight performance issues that would come as a result of the fix; however, the cost of flexibility outweighs the minimal performance decrease, in my opinion. Here’s what I did:

document.observe(’dom:loaded’, function() {

// error checking, reading images into an array here
images.each(function(i) {

if(i != images.first()) {

i.hide();

}

});

});
Event.observe(window, ‘load’, function(evt) {

// apply some specific styles to the images here

});

Ultimately, this still allows me to hide all of the images prior to them being displayed so none of the actual visuals are affected, but I delay the image processing until the images are actually loaded by the browser. This proved to completely fix the bug in Opera and also stopped the inconsistency issues in Safari.

As I mentioned before, I’m not 100% positive that the results of my testing are correct, but it seems to be close based on the results. Additionally, this fix ended up addressing the cross-browser quirks so I’m content with the solution. If any of you are familiar with the issue that I was having, or have had any similar experience, leave me a comment.

Later, I’ll go more in depth on this library that I’ve been working on, but I’m not quite done with it so there may be more issues to discus.

Until then,
Tom

Recently, I’ve been working on an application that, upon the successful completion of an AJAX request, injects some HTML into the current DOM. While working on this project, I kept getting an “Unknown runtime error” message in IE6 and IE7 all the while Firefox was responding the request by injecting the HTML exactly as I wanted. Before you go hating on IE and loving on Firefox (which I was guilty of doing), read on - IE was actually doing the right thing, just in a poor way.

What was wrong?
Here’s a snippet of my JavaScript as well as a comment as to which line was causing the problem:

if(response.get_responseAvailable()) {

…
var div =
document.getElementById(’divJobInformation’);
// here’s the problem…
div.innerHTML = response.get_responseData();
…

} else {

…

} // end if/else

Basically, what’s happening here is that, permitting the response has completed successfully, it brings back a chunk of HTML that I want to place in my current page. Unfortunately, it was halting on both versions of IE and displaying this error:

Just to make sure I had covered all my bases, I double checked my Firebug console and it wasn’t reporting any error at all. I ended up trying out a couple of test cases to see if I could pinpoint the problem. First, I tried to simply inject a string literal into the DOM. It worked. Next, I echoed the response data into a JavaScript alert box. Everything was displaying fine.

So what did you do?
After coming up empty there, I ended up going through some of the application code that was responsible for handling some pre-processing of the page into which I was trying to inject this data. Now, I’m someone that tries to comply with W3C standards in every way possible, but I failed here: What I ended up finding was that some of the data that was coming back from the AJAX request contained a block level element and it was being injected into an inline element. That’s bad style, and I should have caught it sooner, but I was knee deep in code and I failed to catch it. I couldn’t see the forest through the trees, so to speak.

Did you bother verifying this?
Yep. After I got the rest of the application working, I wanted to make sure that I fully understood what the problem was, and to verify that it was repeatable in all (or almost all) cases. I ended up making a quick sandbox page that would allow me to dynamically choose a single containing element and then trying to inject a collection of other elements into it. One example would be trying to place a header element in a paragraph element. IE threw an error for every one of the tests I ran, Firefox let it slide.

But there’s a catch: If you were to place a header element inside of a paragraph element in your HTML source and then load it up in a browser, it works fine - IE will actually parse it and display it with no errors. If, however, you attempt to inject a header element into a paragraph element after the DOM has loaded, it will throw an error every time.

Surprisingly enough, IE (instead of Firefox) is actually doing the right thing by rejecting this attempt to insert response data in an ill-formed manner. Unfortunately, the error message that it returns gives you almost no direction into which way to really start debugging the script. Maybe I should have caught this from the get go, but judging by a quick Google search, it seems as if others have experienced similar pains.

If you’ve got any thoughts, comments, questions, or more experience with this stuff, leave me a comment!
Tom