Using Dreamweaver CS4 SPRY’s to read cross-domain XML files

Posted by Panda on Friday September 11, 2009 in Life / Work / Home / Money, Technology / Multimedia / TV

Before we begin, I am writing this because…

1. I will no doubt need it again in the future and at least then I will have a record of how I did it, and…
2. I hope that Google indexes this post so that others can benefit from it.

When I was looking for a solution to this myself, I came across stacks of information online – but nothing that put ‘2 and 2’ together. I found plenty of articles about using SPRYs in Dreamweaver CS4. Then there was information on cross-domain hacks and workarounds (because I want to grab content from different domains & servers). Then, finally, there was heaps of information about proxy scripts that would get the content for my scripts (to work around the whole cross domain security thing). But like I said, I couldn’t find anything, even in the Adobe forums, that would put all three things together for me so I could make the damn thing work. Hopefully this post does that for you!

The idea behind Adobe’s SPRYs (I use SPRYs in Dreamweaver) is great – in particular, their ability to read XML or HTML files, look at the content, and display is in virtually any way through a series of variables. For content publishers like me, it makes a hell of a job much easier… particularly when I often need to make updates to at least 20 product websites which display similar content (but are hosted on different domains and servers).

The technically-minded readers will have noticed a particular thing that I just said – “hosted on different domains”. Ah yes, the old cross-domain chestnut! The XMLHttpRequest browser security model prevents scripts from getting content from other servers & domains (if it was just “other servers”, it wouldn’t be so tricky – but we have stuff on multiple domains too, with one central domain serving all images, CSS, scripts, RSS feeds and so on).

In essence, my question is: How do I make it as easy as possible to update 20 websites when something changes (without using a CMS; they’re generally too restrictive)? General product content isn’t much of an issue – it doesn’t change too often; but we post news articles & blogs fairly regularly at work, meaning that RSS feeds need to be updated, and so forth. And then I want to display news & blog updates as plain HTML – not inside an RSS feed (you can generally do more with it this way, including displaying it in a nicer fashion).

So again – how the hell can I use one single file (for ease of updating) and display it in different ways across 20 different websites? Not knowing too much about this stuff, I began by tinkering with crossdomain.xml – then, after about half an hour of wondering why it wasn’t working, I realised it only works for Flash files, not HTTP requests. LOL! *facepalm*

I began searching the Adobe Labs forums for info on their Dreamweaver CS4 SPRY technology (the link is http://forums.adobe.com/community/labs/spry, FTW). There was plenty of talk about cross-domain issues on there – Adobe’s help files even spoke of it, but people in the forums kept linking off to 3^rd party PHP scripts that would emulate a Flash file requesting the content (in which case, crossdomain.xml would work – because the server serving up the RSS feed thinks it’s a Flash file and, if it’s allowed in crossdomain.xml, permits it to proceed).

This would probably work just fine (I haven’t tried it myself though) – but again, there was no information for a relatively novice programmer like me on how to integrate the script with the Dreamweaver SPRY for reading XML files. So again, back to square one… where to find a cross-domain transporter that I can easily integrate with Dreamweaver’s SPRYs for reading XML files I have hosted on another domain.

Then, finally, I found a post where someone has written something about an API on the Yahoo Developer Network that acts like a proxy – grabbing the file for you (to bypass the cross domain issue) and then allowing you to work with it as if it were hosted locally on the same domain.

Here’s a copy of the file’s content – save it as proxy.php

<?php

// PHP Proxy example for Yahoo! Web services.

// Responds to both HTTP GET and POST requests

//

// Author: Jason Levitt

// December 7th, 2005

//

// Allowed hostname (api.local and api.travel are also possible here)

define (‘HOSTNAME’, ‘http://somewebsite.com/rssfeedurl.xml’);

// Get the REST call path from the AJAX application

// Is it a POST or a GET?

$path = ($_POST['yws_path']) ? $_POST['yws_path'] : $_GET['yws_path'];

$url = HOSTNAME.$path;

// Open the Curl session

$session = curl_init($url);

// If it’s a POST, put the POST data in the body

if ($_POST['yws_path']) {

$postvars = ”;

while ($element = current($_POST)) {

$postvars .= key($_POST).’=’.$element.’&’;

next($_POST);

}

curl_setopt ($session, CURLOPT_POST, true);

curl_setopt ($session, CURLOPT_POSTFIELDS, $postvars);

}

// Don’t return HTTP headers. Do return the contents of the call

curl_setopt($session, CURLOPT_HEADER, false);

curl_setopt($session, CURLOPT_RETURNTRANSFER, true);

// Make the call

$xml = curl_exec($session);

// The web service returns XML. Set the Content-Type appropriately

header(“Content-Type: text/xml”);

echo $xml;

curl_close($session);

?>

Notice the 9^th line – define (‘HOSTNAME’, ‘http://somewebsite.com/rssfeedurl.xml’); – make sure you replace the text in the middle there with your actual RSS feed.

Now, when you setup your Adobe Dreamweaver SPRYs, insert the SPRY as normal, but jump into code-view and change the JavaScript (where it goes and grabs the XML data) so that instead of opening the XML file, it opens the above proxy.php file. Because line 9 of the above proxy.php file tells it which XML file to open, your SPRY script will know which file to open. Easy as that!

And the best thing? It just works (even when you have PHP’s ‘safe_mode’ turned on)! Neato! Hopefully this helps you if you have the same issue – feel free to contact me if you need more info, or a hand with your scripts. Until next time…