No Mod Required

98.75% Billable With Friday to Go.

As I mentioned on Saturday, this has been my first really busy week at work.

It's honestly nothing compared to some of the days and weeks I saw in 2000 (working full time for one startup-Advisortech and moonlighting for another- Boston's Weekly Dig), but it's still somewhat invigorating to go through this sort fo fire drill from time to time.

Unfortunately the work itself is mostly mind-numbing. Cosmetic changes to a site where all the fun work (a little Google maps mash-up and an Ajax log-in) was finished weeks ago.

Speaking of which, the Ajax log-in was the first time I've used the hidden iframe mechanism for talking to a server. In a lot of ways I like it as it relies on more of the standard browser mechanisms to get at the data. For example, if the work weren't based on status codes, I never would have given them a second thought. Compare that to the hoops you have to jump through with the the XMLHttp object (checking both HTTP Status and HTTP Ready States) and it looks like an appealing option. I mean, this is the entire log-in function

function login() {
var remember = "N";
if ($("remember").checked==true){
remember="Y"
}
var theurl="/api/auth/signin?username="+$('username_field').value+"&password="+$('password_field').value+"&remember="+remember
$("login_controller").src=theurl
}

All the rest is handled by $("login_controller")'s onload event, which fired a function that made some DOM manipulations to display the correct messaging. Really pretty easy, all things considered.

There was one really strange issue- the way IE handles the DOM of an XML document in an iframe. Instead of doing the expected (AKA what Firefox does, namely returning the clean XML DOM of the src document) IE returns the DOM of the color-coded, IE rendered document.

Thanks to the new IE Developer Toolbar, I can now show you exactly what it looks like. I can also see it for myself, since I could only really explore it before with their old DOM inspector and with code. In code it would return ludicrous results for getElementsByTagName("*").length. I would get double digits tags for a four or five node document.

This is just the briefest snippet of the rendered DOM of the feed for this blog.

<BODY class="st"><DIV class="e"><SPAN class="b">&nbsp;</SPAN> <SPAN class="m">&lt;?</SPAN><SPAN class="pi">xml version="1.0" encoding="UTF-8" </SPAN><SPAN class="m">?&gt;</SPAN> </DIV><DIV class="k"><SPAN><A class="b" style="VISIBILITY: hidden" onfocus="h()" onclick="return false">-</A> <SPAN class="m">&lt;!–</SPAN></SPAN> <SPAN class="ci" id=""><PRE> generator="wordpress/2.0.7" </PRE></SPAN><SPAN class="b">&nbsp;</SPAN> <SPAN class="m">–&gt;</SPAN><SCRIPT> f(clean);</SCRIPT> </DIV>

Which translates to this in the original XML:

<?xml version="1.0″ encoding="UTF-8″ ?>
<!– generator="wordpress/2.0.7″ –>

I understand that they have to return the referenced document's DOM. That's fine. They just need to leave the referenced document alone unless there's a real reason to muck with it. Making an XML document pretty isn't a real reason.

It is easy to fix. All you need to do is attach a blank style sheet to the XML doc and everything will work as expected. Still, getting to the point where I understood what was happening and how to fix it was quite an odyssey.

Leave a Reply

Note: Wrap all of your code blocks in <code>...</code> and replace < and > with &lt; and &gt;, respectively.