Current plan for FeedFeeder v2

Somehow this blog post stayed in draft mode forever. But it details the plans I have for FeedFeeder v2, plans that seem to be pretty solid.

The problem with my previous FeedFeeder v2 architecture is that it tampered with something that was not broken; the basic FeedFeeder architecture. Why do code cartwheels when the use of Collections can do all the work for you?

The new idea is to have each FeedFolder be responsible for a single feed. Attributes to handle special cases (generally broken feeds your customer demands you handle) will be hung off the FeedFolder in which FeedItems will be generated and reside. If you need to combine multiple feeds then you just use a Collection. No need for a special FeedDefinition content type, keeping the architecture simple and ensuring that the code remains straightforward.

The quick-and-dirty UML above is nearly identical to the way FeedFeeder v1 is built. I've just added a 'rules' lines attribute. It could be more accurately be called 'feedParserEdgeCases', and will let you correct some of the funny cases you get when your customer says, "I need to have our site recieve feed from Joe Schmoe's bad feed and it has to happen next week!" In the case below, JoeSchmoe has decided to change the Title attribute in his Atom feed to JoeSchmoeTitle.

'JoeSchmoeTitle => Title'

Basically the idea will be that through a simple dialogue like the one below, you'll tell FeedFeeder to take the value of JoeSchmoe's custom title and put it into the correct FeedItem attribute. And you'll be able to do it without any custom/hard coding!

The credit for this goes to the Van Rees brothers. They looked at my crazy thoughts, forced me to defend them, and tossed in great ideas when they grokked the rantings of my insanity. ;)