Although an XML feed from ROUTES has been available for some time (and as Ive mentioned in various posts before), I'm not sure how widely it's being used to actually feed ROUTES information into other pages. Some course eDesktop pages do republish ROUTES information, and it's quite possible that this is captured from the ROUTES feed in some way (e.g. when publishing a site from its XML template), but a quick inspection of the ROUTES site itself suggests that the ROUTES search pages do not use the XML feed to display the results?
Why should they, though? Well, as ever, when I get a glimpse of how a Javascript trick works, I think it should be applied everywhere!;-) And the latest thing I've been tinkering with is xmlhttprequest... Now I know this has been around for a long time, but I've only recently just started to play with it, spurred on in part by it's 'rebranding' earlier this year as AJAX (Asynchronous JavaScript and XML).
One of the main attractions of xmlhttprequest is that it can be used to modify content within a page with new content obtained from a server, without having to refresh the page. This generally makes for a far smoother user interaction, and also means that you cut down on exposing the user to messy URLs in the browser address line.
To give a quick example, here's a link to a ROUTES-XML search on the keyword Technology. The file I'm calling is actually a capture of a ROUTES-XML response - the xmlhttprequest security policy has been defined to prevent requests being made from one domain to another, so I can't actually make a request to the ROUTES-XML service itself.
Once you click on the link in the test page, an xmlhttprequest is made to a test page, which returns the search response as an XML document. A Javascript function then parses this result, modifies the structure of the current page, and displays the result without having to reload the page.
Now that's all well and good, but you'll notice a few issues perhaps. In the first instance, the URL displayed in the list of results (now shown above, if you clicked on the link) are broken. What seems to be happening is that when I create an anchor link, it is being set relative to the local directory. Now I'm not sure if this is down to me (probably!) or an enforced security policy - as I'm doodling this offline, I can;t check just at the mo. [yes, it was my problem, of course...the query returns a URL filled with ASCII character codes, so the URL isn't recognised as a URL*... An alternative approach I should have noticed would have been to parse the resource ID field, and then append the ID number to a URL stub...]
Anyway, it does bring at least one thing to my attention, which is that the ROUTES-XML feed is really messy... How much cleaner would it be if the ROUTES-XML links could:
a) all be made relative to a common root domain (http://routes.open.ac.uk, for example), and
b) cleaned up path-wise by using a redirect (e.g. redirecting from ixbin%2Fhixclient.exe%3F_IXDB_%3Droutes%26_IXSPFX_%3Dg%26submit-button%3Dsummary%26%2524%2Bwith%2Bres_id%2Bis%2Bresnnnn to routesID%2Bnnnn
* Here's the js fix, which should be applied to the URL:
function unASCIIChars( s )
{
s = s.replace ( /%3A/g, ':' );
s = s.replace ( /%2F/g, '/' );
s = s.replace ( /%3F/g, '?' );
s = s.replace ( /%3D/g, '=' );
s = s.replace ( /%26/g, '&' );
s = s.replace ( /%2B/g, '+' );
s = s.replace ( /%25/g, '%' );
return s;
}