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

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 3rd 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 9th 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… 🙂

8 Comments

  1. Saturday December 11, 2010  7:25 am by Marco Reply

    Hi and thanks for this useful posting, I'm in need to sort out the so called crossdomain Server script and wonder if this would work to get HTML data too, maybe if I change the http://somewebsite.com/rssfeedurl.xml with http://somewebsite.com/mydata.html and the var from xml to html..

    ; )

  2. Saturday February 12, 2011  4:08 am by Edward Reply

    Is there a way to test the PHP to see if it's working prior to being used in the Spry Data Set?

    • Saturday February 12, 2011  9:57 am by Andy Reply

      Yes, there is a way to test is PHP itself is working. Create a "phpinfo" file (instructions: http://www.mirrorimages.net/mi_faq.php?do=a&cid=4&id=48), upload it to your site & then surf to it. If it displays lots of PHP stats & information, then PHP is running fine. If it prompts you to save or download the file, then PHP isn't working/running properly & your host will need to configure it for you. Hope this helps :-)

  3. Friday February 25, 2011  7:24 am by Edward Reply

    I like this idea but I still can't get it to work. Here's my links...

    Webpage to display data...
    http://www.njn.net/edtest/wordpressfeeds/wpfeed2.html

    Feed I want data from...
    http://njnnewspublictv.wordpress.com/feed/

    Proxy.php...
    http://www.njn.net/edtest/wordpressfeeds/proxy.php

    • Friday February 25, 2011  7:40 am by Edward Reply

      Ok, I think it is working, but I don't have the exact feed url correct for my wordpress.com blog. Any ideas?

      • Friday February 25, 2011  8:06 am by Edward Reply

        I think I figured it out! The full url you need is http://njnnewspublictv.wordpress.com/feed/wp-rss.php.

        Sorry for all the comments!

        • Saturday February 26, 2011  12:23 pm by Andy Reply

          No problems - I'm glad you worked it out :-)

  4. Pingback : » Using Dreamweaver’s SPRY to display Wordpress Feeds on your domain

Leave a reply

Your email address will not be published.

My Investment Journey (Part 2)

Last time, I left you to ponder over the start of my journey into investing. This time 'round, I'll take a look at the next phase of the process - filling in the forms and making t[...]