The other week I was experimenting with the HTML Canvas element for another little side-project of mine when I was reminded of the Graph Plot screen which my old calculator has. Essentially it lets you enter a Cartesian equation which it will then plot on the screen.

Subsequently, over a couple of days I put together a Javascript powered equation plotter, with much the same functionality as my TI-83. Oh and in the process I found a bug in the WebKit nightly, which they swiftly fixed.

You’re free to use the source to the how you wish, if you’re that way inclined (it’s a client-side web script so it’s practically open source off the bat). Under the hood it makes use of the MooTools javascript framework, though I’ve not made use of its features extensively, so It would only be a matter of an evening’s work to remove this dependancy.

The first project ran afoul of bug #6669818 which prevented the applet from connecting back to the originating server during LiveConnect calls, in Mozilla Firefox on a Windows XP platform.

Fortunately there is a workaround for this; by passing the task off to another thread which was started in a non-LiveConnect part of the Applet’s lifecycle, the task is then executed in another thread which is not subject to the same malfunctioning security check.

If you’d rather not have to create a thread just for this, a quick hack is to pass the event off to the applet rendering thread using the SwingUtilities.invokeLater(Runnable); function.

In the second project I’ve now encountered another platform-specific Applet quirk, this time with Mac OSX.

Using Javascript it is possible to change the size of an Applet on the page in the same way you would any other DOM element, however on Mac OSX any browser using the Java Embedding Plugin (Firefox, Opera and others) will fail to resize Java Applets correctly.

I’ve knocked up a simple test page which allows this to be tested, and shows a potential workaround.

There appear to be two problems cropping up; the first is that the Browser does not notify the Applet that it ought to resize. If you leave the “Notify Java” check-box un-checked when submitting the form, the browser expands the area the Applet ought to be using, but the applet continues to draw in it’s original position.

The second issue is that when axis are changed and Java is manually notified the behaviour still does not perform as it ought to. The clipping region of the Java applet rendering is not updated correctly, and thus only part of the applet is correctly rendered.

There is a temperamental workaround for this, by programatically resizing one axis and then the other in quick succession, but this seems to fail as often as it works, depending on whether the page is being loaded from nothing, refreshed, no-cache refreshed or returned to via the browser ‘Back’ action.

In the interest of getting this bug fixed the code to the Applet resize test page is linked from the test page and free for all to use.

Bugs:

• Java Embedding Plugin tracker: #2030298
• Firefox Bugzilla: #451882

The controls on Mac OS X are less restrictive, but still restrict you to pause, fast forward or stop, however some simple javascript manipulation of the page can enable the regular RealPlayer controls, complete with a seek-bar.

Bookmark either download the source file or view the bookmarklet source. Unfortunately blogger won’t let me create an actual bookmarklet link, so you will manually have to save the bookmarklet into a bookmark in your browser.

Back when
I was writing my Google Maps property finder I was using Google’s Geocoding API to get a set of co-ordinates based on a search string.

Specifically I was using the getLocations method of the GClientGeocoder object.
This would return a number of Placemark objects with a bunch of information about the potential matches.
They don’t really document this object, but to be honest they don’t really need to, below is an example Placemark expressed in JSON-ish notation.

{   "id": "p1",
    "address": "1600 Amphitheatre Pkwy, Mountain View, CA 94043, USA",
    "AddressDetails": {
        "Country": {
            "CountryNameCode": "US",
            "AdministrativeArea": {
                "AdministrativeAreaName": "CA",
                "SubAdministrativeArea": {
                    "SubAdministrativeAreaName": "Santa Clara",
                    "Locality": {
                        "LocalityName": "Mountain View",
                        "Thoroughfare": {
                            "ThoroughfareName": "1600 Amphitheatre Pkwy"},
                            "PostalCode": {
                                "PostalCodeNumber": "94043"
                            }
                        }
                    }
                }
            },
        "Accuracy": 8
        },
    "Point": {
        "coordinates": [-122.081783,37.423111,0]
    }
}

The only thing is, if you want to get a specific element, the tree will not necessarily be the same each time, so traversal is a pain.
The code below will condense all this into the root level of an object, so you can pick out the key/value pairs you want, and easily tell if some aren’t there.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

var Placemark = new Class({
    initialize: function(placemark){
        this.traverse(placemark);
    },
    traverse: function(item, key) {
        for (var key in item) {
 
            if (key == 'prototype')
                continue;
 
            if(typeof(item[key]) != 'object')
                this[key] = item[key];
            else
                this.traverse(item[key]);
        }
    }
});

One thing to note is that this was written for to use the Mootools class system, though it shouldn’t be very hard to remove this dependancy.