Ceci n'est pas un blog

I just uploaded v1.0.1 and it can be downloaded here. The new version has the following changes:

• Adds support for http://-URLs through the LWP and URI modules.
• If the URL contains linked script files (e.g. <script src="foo.js">) it'll try to fetch the file and print it too.

This one started when I was approached by a former colleague of mine asking for some help with a calendar script they were using in a secure server environment (https://). Entering dates using a calendar tends to be a bit easier for many people than writing them in. I had a look at the script and couldn't really find anything odd about it, the general function for showing the calendar going something like:

function showCalendar(targetForm, targetDate) {
  // code to create HTML for calendar went here

  // code that opens and writes the calendar
  var calWindow = window.open('', 'calendarWindow', ...);
  calWindow.document.write(lotsaHTML);
  calWindow.document.close();
}

This code was called by links in the calendar window whenever the user wanted to navigate back/forward a month, and that functionality didn't work. I failed to spot obvious errors in the code and sent off some code being a shot off the hip, but it totally failed to solve the problem. I then suggested to rewrite the code so that it reused a global window reference whenever it's available. The code became:

var globalWindowRef;
function showCalendar(targetForm, targetDate) {
  // code to create HTML for calendar went here

  // code that opens and writes the calendar
  var calWindow;
  if(globalWindowRef && !globalWindowRef.closed) {
    calWindow = globalWindowRef;
  } else {
     calWindow = window.open('', 'calendarWindow', ...);
  }
  calWindow.document.write(lotsaHTML);
  calWindow.document.close();
}

The reason why I believe this worked while the other didn't was that the links in the calendar window were javascript:-URLs calling showCalendar() found in the parent window, which in turn tried to reopen (and then rewrite) the calling window before the function had returned. Something which doesn't seem to be allowed (anyone see any reason why it should?). Goes to show that once you're going secure you should look through your code another time to make sure it's doing what you believe it's done, and doing it in a sane manner.

I recently worked on making my "tree menu":http://www.treemenu.com/ work with Opera 6 & 7 and noticed that v7 died with an error while trying to grab the frame names in the parent frameset. This is a problem I've never experienced with other browsers except Opera v5, and in that case I was able to fix it by letting the parent frameset's onload-event handle startup.

Something I had forgotten I wrote. It's from a thread that once existed over on Experts Exchange. Enjoy!

From: ********* Title: "JavaScript and Sex"
Points: 5 Date: Monday, March 13 2000 - 01:48PM CET

Can anyone tell me how I can use my skills in JavaScript to get more girls/sex please.
Thanks in advance
****

From: nettrom
Date: Monday, March 13 2000 - 01:40PM CET

Unfortunately the methods needed to get girls/sex in JavaScript are dependant upon the DOM of each girl. Therefore, you will have to make sure you sniff what version of said DOM each girl has before you try to get them. If you do not do this the result is a fatal error.

Therefore, always start each session with:

var mySelf = new Me();
var myGirl = new Girl();
if(myGirl.DOMversion < 2) {
  myGirl.leave(); // too old DOM version
}

Then you can get the girl, and have sex. It's fairly straightforward, the DOM 2 really helped since it has methods for everything you'd ever want to do. In DOM 1, as you might know, the leave() method might make the girl angry, and you'll exit with a fatal error.

The natural next step of your session is to get the girl. If you forget to do that she'll leave when you try to have sex with her.

if(myGirl.stillPresent) {
  // girl is still with us
  myGirl.get(); // get girl!
}

Now that we've correctly gotten the girl we can undress and have sex. Remember to set the sex.safe property to 'true' first, or else you might end up with another fatal error. The previous lines then become:

if(myGirl.stillPresent) {
  // girl is still with us
  myGirl.get(); // get girl!
  mySelf.undress();
  myGirl.undress();
  sex.safe = true; // must rember to have safe sex!
  myGirl.getOnBed();
  mySelf.getOnBed();
  mySelf.haveSex(myGirl);
}

It's as easy as that.

Tomorrow's lesson: How to have even better sex with the new DOM v3!

Last year I helped an ex-colleague of mine debug a problem with identifiying objects passed to a function in an iframe using the instanceof operator. The problem was that Microsoft Internet Explorer didn't give the expected results and we had to code our way around it. I've been wondering ever since about when theory and practice coincide, and so I created a testcase and tested whether the instanceof operator works as it should.