I-Spry Part 6: Don't Miss the Spry RSS Reader demo--it's "for real"!
Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.Have you by any chance tried the RSS Reader demo app in the Spry download, and kind of yawned because it seems to be static and not "real"?
The problem is that in the download, the Readme.html points to the file demos/rssreader/index.html. Sadly, that one just reads a static XML file that simulates an RSS feed (showing "lorem ipsum" or "greeked" text).
But if you've run the demo on the labs.adobe.com site, you will have seen a "real" RSS feed. What gives?
(As suggested in the entry's title, this is part of a series I'm doing on Spry. Be sure to check out the other entries.)
Gotcha 1: There are really 3 demo files to choose from
Here's the situation: in that demos/rssreader/ directory, there are actually 3 different files available to be run: index.html, index-cfm.html, and index-php.html. The latter two will get real, live RSS feeds. But again, the readme.html doesn't point to them, so you may miss them.
OK, so now you know they're there. Do check them out. As I'll explain in a moment, they hold a key to one problem CFML folks often want to solve when working with Spry. Here are a couple other gotchas.
Gotcha 2: You need to run them on intended servers
If you do run them, note that you have to put them on the respective kinds of servers (index-cfm.html on a CFML server, or index-php.html on a PHP server).
Under the covers, the pages make a request to the named RSS feed by way of CFML or PHP code running on your server, and then send the resulting XML down to the client.
How they get around Javascript/browser security restrictions for requesting XML from other servers
This approach is indeed the way that you get around the Javascript/browser security limitation that would otherwise preclude the client making an httprequest to a server other than the one that sent the HTML page. (In the CFML version, it ultimately calls on a CFM page that does a CFHTTP on the client's behalf.)
If you're wanting to grab some XML from a server other than the one serving your Spry HTML page, and you've found that it doesn't work, this is the challenge and indeed the solution you need. See the demo source for more. Here is another example.
Gotcha 3: You can't request them via the file system
One other gotcha in running the CFM and PHP versions of the HTML pages: you have to request them via a web server. In other words, you can't just open them via the file system (as you can with most Spry demos), but must load them via a URL like http://yourhost/.... Why is that? Because the index-cfm.html page makes its request for that CFM page as (for example):
var dsCategories = new Spry.Data.XMLDataSet("data/feeds.cfm", "feeds/feed/category", { distinctOnLoad: true, sortOnLoad: "category" });
That then causes the browser to try to request the data/feeds.cfm file in the same manner in which the enclosing index-cfm.html was requested. And we all know you can't request a CFM page using the file system!
Gotcha 4: The Labs page demo runs index.html, but it's really the index-php.html
Adding to the confusion in all this, if you run the demo on the adobe labs site, clicking on the link in the RSSreader demo link in the readme.html there, it works "as expected" (real RSS feeds) even though it's pointing at demos/rssreader/index.html. Why does it work there, you may wonder?
Well, if you do a view source of that page there, you see that it's doing the PHP approach. What they've really done is renamed the PHP version to index.html, so that a "real" example shows when people run it there. I can see why they did, but I can also see it confusing some trying to connect all these dots. (Let's not give them grief for not running the CFM version!)
Gotcha 5: Some feeds fail when run from downloaded code, but working on the labs site
One last comment, and it's really separate from the main points above. When I run the page that serves the "real" feed, on my localhost, I notice that several of them fail (they get the error, "failed to load feed items", using the new spry:state tag).
But the version on the adobe live site works fine. I don't know if the difference is their running the PHP version, and my running the CFML one. Or perhaps they've updated what's running there?
When I analyze the HTTP streams coming in on the "failed" feeds, they are indeed receiving expected RSS XML.
Anyway, I leave that for your consideration.
Just don't miss these demos!
Anyway, the main point is that they're just not listed in the readme, so I fear most will miss them. I did, for some time. Hope this helps.
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Can you please tell me what does the feeds.cfm is made of? Does it grab all the feeds serially?
var dsCategories = new Spry.Data.XMLDataSet("data/feeds.cfm", "feeds/feed/category", { distinctOnLoad: true, sortOnLoad: "category" });
This above code defines a dataset and grabs the category of the feeds. But as there are multiple feeds in the demo, I am guessing feeds.cfm contains the URLs to all these feeds. I am not familiar with that much of Cold Fusion, but if you can send me a sample of the code, that would be great.
I've just checked and the 1.6 download (http://labs.adobe.co...) does still have the sample apps including the feed reader I was pointing to, and that very feeds.cfm you are looking for.
I recommend you just get and look at it rather than me detailing what it does, but the bottom line is that it reads in the livefeeds.xml file (in the same local directory) which has among its elements the URL for each feed, and it uses CFCONTENT to send the XML file down to the browser (loaded into the Spry XMLDataset as you see in the code fragment you've shown). It's then up to that Spry feature and related code in the index file to process it and create the spry widgets.
There's really nothing CF-specific about the process. There is an example there as well that uses PHP (an index-php.html and corresponding feeds.php) and a plain HTML one (index.html) that just reads in a localfeeds.xml file on the local machine. The CF and PHP examples simply demonstrate how one *could* obtain the list of feed URLs from something driven on the server.
Again, I recommend you download the framework, its docs, and its demos (all in the one zip) to better understand things. My blog really isn't a place to elaborate on all this. The Adobe forums would be the better place if you have still more questions. Hope that helps.