The core of Eventsites is a single-page Javascript application.
On visiting the site, a user receives a bare-bones XHTML page that binds all relevant Javascript and CSS files. After loading these files, the script is used to perform the following operations:
- Parse the event-ID from the URL, e.g. www.eventsites.co.uk/evdb/events/E0-001-000935917-5 equates to event ID E0-001-000935917-5. An invalid or non-event URL simply routes to the site homepage.
- Pull event data from EVDB using a REST request. The REST URL for the Carson Future of Web Apps would be: http://api.evdb.com/rest/events/get? &id=E0-001-000935917-5&app_key=mCzrkKSxK43TMhtN
- Parse data from the EVDB XML response
- Construct and despatch a request for the event Flickr RSS feed. In the Carson case, this would be: http://www.flickr.com/services/feeds /photos_public.gne?&format=rss_200 &tags=futureofwebapps
- Parse the Flickr feed to retrieve photo URL's
- Construct the application XHTML interface
- (on map select) create and initialise a Google Map with the event latitude / longitude
- (on photos select) create an XHTML photo gallery using the URLs specified in the Flickr feed
<body onload="new Application()" />
All the XHTML in Eventsites is built using Javascript DOM methods. I'm not a fan of using getElementById to attach methods to existing XHTML. I don't like the approach because it lacks any formal binding between the code and the structure - change an ID in the XHTML file and your code can't bind to the interface.
Building the XHTML in the code ensures that interface and its behaviours are bound together by definition.
Making XHR cross-domain
Eventsites uses the XMLHttpRequest object to pull in data from EVDB and Flickr. Unfortunately, since XHR is limited to same-domain calls, we need a server proxy to redirect these externally.
The proxy script that is used in Eventisites is shown below:
<?php
$remoteURL = $_GET['url'];
$pos_int = strpos($remoteURL,'http://');
if($pos_int===0){
$fp = fopen($remoteURL, 'r');
header('Content-type: text/xml');
if($fp){
fpassthru($fp);
}else{
echo
'<?xml version="1.0" encoding="UTF-8"?>
<root connection="false">
<eventsites_message>
Failed to connect
</eventsites_message>
</root>';
}
}
?>
This script simply sends a GET request to any address passed in the url argument and passes on the data that's returned.
You can see the script in action at: http://www.eventsites.co.uk/remote_proxy.php and its functionality can be seen by requesting the event's photo feed (URL encoded).
Handling URL's
As mentioned, Eventsites is a single-page application. This means that although the ID for an event is specified in its URL, e.g. www.eventsites.co.uk/evdb/ events/E0-001-000935917-5, all such URLs must still map to the same document on the server.
This could be done with mod_rewrite but since I haven't the faintest idea how mod_rewrite works, I worked the same magic using simple old .htaccess.
.htaccess allowed me to very simply specify the 404 error page as being the frontpage. All URL's that don't correspond to files present on the server just route back to root.
The root level .htaccess file for the domain is:
ErrorDocument 404 /
Once the frontpage has loaded, Javascript accesses the window.location object, and uses a regular expression to parse the event ID.
Next
Why XHR needs to become opt-in cross domain
Update:
As a number of people correctly pointed out, my server proxy originally gave full read access to the local file system. Although this was something I'd forbidden in earlier incarnations of the code, I filtered it out for the sake of making the essence of the code as understandable as possible. Not a smart thing to do though and all URL's are now filtered (as shown in the code) to make sure they're external.
What if all this generic functionality was provided pre-packaged for us though? What if we could buy tagging or asset management wholesale via web-services? 
hard part is already done for them? 
