As a followup to my previous post on an IG module for ning photos, here's another for Ning bookmarks.
My friend Dylan, who works on IG pointed out in a comment (very politely even if he didn't have to :-)) that neither document.getElementById() or XmlHttpRequest replacements are required. So who to believe eh? The dude who spent an hour looking at the thing one Friday at 11 pm (i.e., me)? Or the person who built the thing? Well! As a blogger, I *know* it should be me!! hehehe. I guess that the disclaimer Google should add is "Don't try this at midnight after an 18-hour workday and then think it's our fault. Go to sleep and check back in the morning." :)

Seriously though, I apologize for the mistake, nothing more frustrating than seeing bad information being spread (I've amended the original post and linked to this one). I was thinking about why I made that mistake though, aside from being a bit tired perhaps. And I think I know why, having written a second module now: it's the caching system that really confuses me quite a lot. You make one mistake in the file, try to test it, and the previous version loads or doesn't depending on unknown circumstances. Then suppose you pass a wrong parameter to an NXSL call -- the JS console or Venkman both lead you into the Google JS code, which is all compacted into meaningless statements. You get errors like, for example "a is not an object" which isn't particularly useful. So debugging a module becomes a fairly painstaking process of load, reload, add and re-add. At least when you are a n00b using the IG framework, like I am.

Now, I know for experience that these things are hard to do, so my suggestion (assumming it's not done already somewhere, but I honestly can't find it--and I'm sure that if it isn't they're already thinking about that, so this just counts as a +1) is for the doc to suggest some way to create a sandbox for developing that gives better debugging info or provide more clear instructions on how to do reloads when things don't work. And that development modules start off without creating a cached copy, instead of the other way around (thus caching what is quite possibly a module that doesn't work).

Anyway, moving on... nothing to see here! And thanks Dylan for setting me straight. :)