CFFEED Reading: Observations & Critique
from: Big Damn Heroes (MXBlogspace)Added: 2008-04-23 18:42:33.0 | comments: 0
I've been playing with CFFEED today, and I've noticed a nice touch, along with some issues and oddities:
- GOOD: Even if you don't end up using CFFEED to parse a feed, using the tag's @xmlVar attribute to fetch the raw XML will result in xml:base being resolved "for free".
- BUMMER: The above only applies to Atom feeds. Granted, few people try to use xml:base in RSS feeds, but there's nothing in the RSS spec that says you can't.
- MAJOR BUMMER: The XML returned by @xmlVar is rewritten to some extent. In most cases, I suspect this won't cause any problems... for example, its habit of declaring a bunch of unnecessary namespaces on the root element of every feed won't usually hurt ya. But I've now seen it strip @xml:base from an atom:link element, so I really don't trust it much. If you're doing things like storing hashes of entries or entire feeds, look out.
- BUMMER: CFFEED doesn't recognize Atom elements within an RSS feed. There are all kinds of uses for RSS+Atom (USM, for example), so this is an unfortunate omission.
- ODDLY ENOUGH: If you declare something like @xmlns:dc="http://foo.com" on the root element of a feed, CFFEED will promptly overwrite it on the root element, and then append your custom declaration to each element that uses it. I guess it works, but 'tis very strange all the same.
- MAJOR BUMMER: It appears that CFFEED fails to resolve xml:base on XHTML contained within atom:content and atom:summary elements. Don't know how that one slipped by, given that the main reason for supporting xml:base in Atom is to allow URI fragments within content payloads.
- MINOR BUMMER: More xml:base fun! CFFEED fails to properly resolve the URIs provided in the atom/generator/uri, atom/logo, and atom/icon elements. I haven't tested it, but I suspect the same is true for the uri sub-element of Person constructs, such as atom/author/uri. In fairness to the CF team, my own RSS/Atom code fails this test as well.
- BUMMER: As I noted during CF8's beta period, CFFEED flubs the parsing of XHTML content elements. As detailed in the Atom 1.0 spec (and in opposition to the Atom 0.3 pseudo-spec), the div container that encompasses an XHTML fragment is NOT part of the content payload, and should be discarded.
In general, if you're using CFFEED to grab a known set of feeds, you're probably gonna be fine. But if you're doing something more general-purpose, I'd recommend sticking with my RSS/Atom Feed CFC.
Wholly Unscientific Praise for CF8
from: Big Damn Heroes (MXBlogspace)Added: 2008-04-17 16:01:47.0 | comments: 0
I've been running this site on CF6.1 since 2003. Now it's running on CF8.01. And wow, is there a difference.
Now granted, other things have changed as well. I've gone from MySQL4 to MySQL5, from a single CPU/single core P4 to dual processor/dual core Xeons, and from 1GB of RAM to 2GB. So I'm not giving CF all the credit.
But the bottom line is, average request times have gone from the high hundreds of milliseconds to <100ms. CPU utilization has gone from averaging well over 50% and spiking to 100% to averaging 2% and spiking to 35% on occasion. That's with no major code changes or query rewrites.
On the old box, jrun.exe ate the machine alive. On the new one, it minds its manners.
Again, all I can say is "wow".
Dear Developers: Flash Forms Suck!
from: Big Damn Heroes (MXBlogspace)Added: 2007-09-07 07:15:11.0 | comments: 0
So I decide to order a product upgrade on Adobe's site (Premiere CS3), and I begin the checkout process. The site immediately asks for my username/password, and I prepare to provide them.
Whoops! Adobe decided to use Flash for their login form, so when I clicked my RoboForm login button, it kicked back a "no form found" error. This was irritating, but okay... I decided to overlook it as a misguided attempt at eating the corporate dog food.
But after login, things got ugly. On any HTML-based site, I can click the identity button on RoboForm's toolbar, and poof, everything from my name to my credit card's verification code are filled for me. On Adobe's site, on the other hand, I'm stuck re-entering a bunch of info that my computer should be handling.
Make no mistake, folks... this may seem like a minor complaint, but it's the kind of thing that can really piss off your users. After all, Flash forms are completely unnecessary, and deprive the user of all the conveniences that modern browsers and extensions provide.
End of rant.
CF8 Beta and CFFEED
from: Big Damn Heroes (MXBlogspace)Added: 2007-06-06 06:36:18.0 | comments: 0
Wow, I haven't posted here in a while! I'm gonna post a few thoughts about Scorpio's feed handling... consider it feedback mixed with observation.
- When an Atom 1.0 content element (or any other text construct) is set to @type="xhtml", then a wrapper div is required for the payload of the element. However, that's all the div is: a wrapper. It's meant to be stripped by consuming apps, but CF8 currently leaves it intact.
- After throwing a couple simple tests at it, CFFEED seems to resolve xml:base just fine, which is good news.
- Not-so-good news... no apparent support for Atom elements in RSS feeds. Granted, CF apps are unlikely to ever need USM support, but it also locks us out of using things like Atom Threading in RSS.
Bear in mind, the above is derived from about 45 minutes of playing around. Further notes and/or corrections will follow upon a little more face time with Mr. Scorpio.
RSSAtom.CFC 2.09
from: Big Damn Heroes (MXBlogspace)Added: 2006-12-19 17:36:59.0 | comments: 1
Here is the latest release of rssatom.cfc. The only change is added support for simple, item-level geocoding. Feel free to skip this version if you do not have very specific needs.