looks like it is all due to the insertAdjacentHTML call being used in another library. In my case, wz_tooltip. Oh wow did this hurt me. So that horror of a project that keeps on poking its head up sent in another small request… put tinyMCE or FCKeditor into one page on the website. Offered 5 hours. Well TinyMCE is already installed, so I figured this was a chance to recoup a little of my loss on this project. Sure enough, I activated TinyMCE with about 5 lines of code, checked that it worked in Firefox, and billed my money.
Next morning I get a call. The thing doesn’t work in IE. So I try a few quick and obvious things, move around where it gets loaded, try a few different load orders. No luck. Grr. I was going to type out my whole damn process, but I realized that’s not what people want to read…
Short version is: the wz_tooltip.js library conflicts with the TinyMCE library ONLY in Internet Explorer. This is because of a call to insertAdjacentHTML which is an IE-only javascript call (thanks again for embrace and extend M$). As a workaround, you can modify the wz_tooltip file by commenting out from line 397 (inclusive) (thats: if(wztt_body.insertAdjacentHTML) ) down to line 400 inclusive (thats : else if(typeof wztt_body.innerHTML != wztt_u && document.createElement && wztt_body.appendChild) ) And now I’m off to submit bug reports.
What a waste of a morning.
I’m doing some work on a site that uses the google maps API (which is clean, simple and absolutely fabulous, by the way) and I have bumped into a strange problem. When I draw the page that uses the google maps api with smarty everything works fine, generally. However if I put the {debug} tag into the template (which causes smarty to give you a nice little pop-up window of all of the variables it’s working with, and some other great info) google maps stops working.
Recently I bumped into a function I wasn’t familiar with in PHP, It looked like the app I was working in was wrapping just about every constant that they used in the __ function. (Yes, that is two underscores.)
Recently I have been somewhat frustrated with some aspects of my work. (See previous post.) I have decided that in many ways I have wandered off track in my work, and I need to start writing code that I like again. By chasing after efficiency, I have allowed quality to become a second priority, and in doing so have begun to lose morale as well. I feel as if this is a very common problem in modern practical programming, and as if it’s a good thing to explore solutions to. For the last several weeks I have been searching for a book on programming that covered tools, tips and tricks for making yourself feel enthusiastic about what you’re working on, and dedicated to doing it well. So far I have not had much luck.
So what was a wonderful project to start with became a nightmare, but I finally see the light at the end of the tunnel with it. Because this project started off so innocently, and became such a disaster, I feel like I should share some of the mistakes I made along the way, and some of the insights that I have gained in both 1) extracting myself from the problem and 2) not allowing myself to get sucked into issues like this again. So lets start with a little bit of history of the project and the situation and go from there.

I am a huge emacs fan, to the point of having written my own major mode for working in coldfusion when I couldn’t find one that satisfied (rather than moving to another editor) Its something that I see as part of my personality, almost like a political affiliation. I also happen to be using a mac at the moment, and my first few tries at using emacs under osX went pretty poorly, but I did work everything out, and I thought that I would write about it some to save everyone else the trouble.