This URL is the kind of thing one encounters when working with Web Map Services:

It returns a geographic map image based upon the name/value pairs passed in the querystring. Google Charts work in a similar way:

To tackle such long URLs I’ve developed the boringly-named URL Editor.

Find it here: http://gingerbbm.com/urleditor

It’s a pretty simple JavaScript application (using Prototype and Scriptaculous) whose main purpose is to split the long querystring of a URL into its constituent name/value pairs in order to dramatically improve legibility. Paste a URL into the main box, click Split, and the name/value pairs appear below:

Once a URL has been split, any edits to the individual values are immediately applied to the main URL, and vice versa.

The Encode and Decode buttons attempt to encode/decode any relevant values that exist.

Click Open to open the URL in its current state in a new window/tab. And Reset resets the whole page.

Reordering of name/value pairs is achieved by dragging them, and you can add and delete them by clicking the relevant buttons.

Bugs

It wouldn’t be hard to trip the application up. The key to it all is the question mark character that denotes the start of a querystring. If you’re not interested in ever opening the URL you can simply start typing into the main box, e.g. “?a=1″, and the name/value pairs will appear.

Names

So, “URL Editor” is a fairly sober moniker, but it was the best of a bad bunch, and being a pretty good description of what it does I decided to go with it.

• U.R.[NOT HEL]L.
• URL Manager
• URL Splitter
• Querystring Dechunker
• Any ideas?

And Finally

I’ve tried it out in FF3, IE8, Safari 3 and Opera 9 on XP and it’s all good. It also appears to work in FF3 and Safari 3 on the Mac. Not tried it on Chrome yet, but I don’t expect any surprises. For me it’s been fairly robust, and a useful tool in my arsenal. I hope others find it useful.

You’ve got a piece of code that creates an image in your web page by passing a bunch of parameters in a GET string to some server-side process:

$('tile').src = 'http://img.com/generate.php?a=1&b=2&c=3';

But what do you do when the URL goes beyond the limit? Practically, for cross-browser solutions, the limit is around 2000 characters (thanks to IE), and I recently had to find a workaround when generating images via a WMS.

The Solution

When we’re dealing with HTML forms, if a GET isn’t big enough we have to use a POST. The difficulty in the scenario described above is that there’s no way to provide the POST variables when making the assignment to the image’s src attribute.

I thought about how to use an Ajax POST but even if image data could be streamed back to the browser in this way, there’s no mechanism for getting it into an HTML image.

And then I discovered the data URI scheme which allows us to assign a base64 representation of an image to an HTML image like so (where the ellipsis indicates the position of the base64 data string):

$('tile').src = 'data:image/gif;base64,...';

If I could issue a POST to the server to generate my image, I could convert that image into a base64 string to pass back to the browser, which I could then utilise in the data URI scheme syntax.

I discovered this method in this brilliant post where the same trick is used to for CSS and to reduce HTTP requests. And by reading that post I learned that we have to do it another way in IE. In IE we have to use MHTML and it involves a little more work on the server but we can still end up with this (where somestring indicates the position in mhtml.txt of the base64 data string):

$('tile').src = 'mhtml:http://img.com/mhtml.txt!somestring';

A proxy script on the server is required to pass the POST variables through to the image-generation program, and convert the resultant image into a base64 data string. Since the WMS I use is located on an external server I was already using Troy Wolf’s PHP proxy script (note that it requires class.php). Converting to base64 is a cinch in PHP:

$base64_encoded_image = base64_encode($response);

I simply added the code I needed to the end of Troy’s proxy script.

So, the flow of events is:

• Client issues an Ajax POST request to the proxy script.
• Proxy forwards the request to the image-generation program and converts the resultant image into a base64 data string.
  • For IE, the proxy saves the string to a file and returns the filename to the client.
  • For all other browsers, the proxy returns the string to the client.
• Client’s Ajax “on success” callback assigns the relevant string to the HTML image’s src attribute.

Anyway, here’s a demo page.
And here’s a zip containing all the necessary files.

A Few Considerations

The IE workaround involves creating a file on the server that contains the base64 representation of the generated image. The format of the file must be as follows in terms of line breaks, and in terms of the double quotes around the boundary parameter:

Content-Type: multipart/related; boundary="_ANY_SEPARATOR"

--_ANY_SEPARATOR
Content-Location:somestring
Content-Transfer-Encoding:base64

R0lGODlh...snip...AACgAACoAAC

The folder in which the MHTML files are generated obviously requires the appropriate privileges. If this method were used in a production environment an automated procedure would be required to delete periodically old MHTML files. IE8 is a great improvement over previous versions and actually supports the data URI scheme, so one day in the distant future all the MHTML workaround shenanigans will be unnecessary. But until then we’re stuck with having to write a file to the server every time – and if we’re doing that it might be preferable simply to write the image to the server and return its URL to the browser. At least it would mean no JavaScript browser-sniffing, and that’s no bad thing.

1. pull down the list of search engines
2. scan for the one I want
3. type and go

To reduce friction when searching in common places I have the following bookmarklets defined.

Google Maps

javascript:p=prompt('GMaps%20search:');if(p)%20{%20p=p.replace(/\./g,%20'/');window.location='http://maps.google.co.uk?q='+p.toLowerCase();}

Dictionary.com

javascript:void(location.href='http://dictionary.reference.com/browse/'+prompt('Dictionary.com%20search:',''))

Prototype API

javascript:p=prompt('Prototype%20API%20search:');if(p)%20{%20p=p.replace(/\./g,%20'/');window.location='http://prototypejs.org/api/'+p.toLowerCase();}

To use these JavaScript snippets, assign them to a bookmark in your browser. For ease of access, place the bookmark on the Bookmarks Toolbar. This reduces the workflow to:

1. click the bookmarklet
2. type and go

It’s not rocket science. A simple Google search reveals all sorts of much-more-advanced bookmarklets. As far as bookmarklets for straightfoward searching are concerned, any more than three or so would feel like too many to me, and I’d opt for the browser’s quick search bar.