ReadyState4

I came across this error on a site I was helping to troubleshoot today and with a little Googling found it happens when you move the DOM containing a TinyMCE editor to another place in the document: TinyMCE loses it’s reference to that original element.

To get around this, showing or hiding the editor won’t work, instead destroying the element before you move it and recreating it (same as the previous post) does the trick:

tinyMCE.execCommand('mceRemoveControl', false, 'idOfElement');
// move DOM element
tinyMCE.execCommand('mceAddControl', false, 'idOfElement');

Sometimes, one needs to remove (not hide) all TinyMCE editors on the page to run a modified version of the global tinyMCE.init code again. This is the best way I’ve found to do it so far:

var i, t = tinyMCE.editors;
for (i in t){
    if (t.hasOwnProperty(i)){
        t[i].remove();
    }
}
// new tinyMCE.init code here

Additionally, you can “destrory” and “recreate” specific editors via:

tinyMCE.execCommand('mceRemoveControl', false, 'idOfElement');
tinyMCE.execCommand('mceAddControl', false, 'idOfElement');

If anyone knows a better way, post in the comments.

I was taking a look at my friend Takashi’s JavaScript tweener which isn’t released yet and noticed he setup his code in a particular way for a few methods that get called dozens of times a second. He explained to me that it was for optimization through memoization. I ran a test case, and indeed it’s much faster. Check it out:

a = {};
a.deep = {};
a.deep.variable = {
    here: 3
}
 
function plain(){
    document.body.appendChild(document.createTextNode(a.deep.variable.here));
}
 
function memoized(){
    var z = a.deep.variable.here;
    return function(){
        document.body.appendChild(document.createTextNode(z));
    }
}
 
 
now = new Date();
    for (var i = 0, max = 5000; i < max; i++){
        plain();
    }
alert(new Date() - now);
 
now = new Date();
    for (var i = 0, max = 5000; i < max; i++){
        memoized();
    }
alert(new Date() - now);
 
// plain:  759
// memoized: 36

There’s a more complex example on the subject posted a month ago on Ajaxian and an easier to understand one on Oliver Steele’s blog written back in 2006.

Today the new WhiteHouse.gov launched and although it isn’t exactly XHTML compliant it beats the pants off of most government websites and follows along with the new President’s plans of deploying a modern communications infrastructure (it’s also using jQuery and jQuery.thickbox as noted above).

Copy on the new site explains: “WhiteHouse.gov will be a central part of President Obama’s pledge to make his the most transparent and accountable administration in American history.”

Regarding Technology, Obama has already talked about:

• protecting the openness of the internet.
• supporting the principle of network neutrality to preserve the benefits of open competition on the internet.
• deploying a modern communications infrastructure.
• getting true broadband to every community in America.

Here’s looking at a tech-positive presidency!

I was helping a friend troubleshoot some of her code today and found the culprit to be a typo in one of her conditional statements:

// var USERID = 12345;
if (USERID =! null){
     // code
}

Her expression was always resolving to true because she had inverted her != (“not-null”) check which was actually assigning her variable to the return of a statement evaluation. Her mistake would be clearer to understand formatted as such:

// var USERID = 12345;
if (USERID = !null){
     // code
}

Since the inverse of false, null, and NaN is true her conditional statement (also an assignment) would always return true.

Which lead me to thinking, the not operator is a great way to write succinct code. In the right context, using the not operator in the right side of an assignment isn’t a bad idea.