We have 3 handlers for Atom, RDF and RSS. All 3 have hardcoded additional vocabularies: ATOM Categories, RDF Categories, RSS Categories which is in some way unusable. I was thinking of merging it to one vocabulary i.e. "Feed Categories" (case 1) or even better to be able to setup vocabulary per feed (case 2).
case 1 (vortal type)
Let's assume I collect many feeds in different formats on more or less single topic. I would like to have feeds with term i.e. "computer hardware" to be accessible for all feeds regarding of their type.
case 2 (portal type)
If I have feeds on different topics I would like to set vocabulary per topic, or even per single feed.
I couldn't think of the case where per feed type vocabularies will be usable...
Removing hardcoded vocabularies in handlers will require to extend parser function by one more parameter:
function _aggregation_XXX_parse($feed_XML, $feed, $vid)
where vid is an id of vocabulary. By this addition we can allow users to name their vocabularies like they want, which will also help non-English sites.
I can provide a patch within 2 weeks if you think it's worth working on it.
Comments
Comment #1
Ashraf Amayreh commentedSounds very logical, it would seem most natural to have one vocabulary collect all terms rather than three different ones.
I would say implementing a drop down vocabulary inside the feed node would allow us to include all of these cases. Do you think we need to pass the vid to the parse functions? I believe that they would naturally pass in with the feed object anyway.
There are a couple of things to think about though, maybe we should maintain some of the current functionality, what if someone wanted to parse a custom XML where parts would be aggregated to a vocabulary and others to a different one? With the new scheme he would lose this option. It may seem far fetched, but it might be a good idea to maintain all options if possible. Finally, how will we handle the update path for existing users? To merge or not to merge, that's the question :)
Currently, I'm working on three things. First, I want to get the patch on updating aggregated items when feed contents change in. Second, I need to integrate the aggregated content with the drupal filter system and finally, I'm really getting bothered by the amount of work I have to do to add one check box to the feed node page so I'm thinking of re-implementing this so adding more options becomes trivial. That would include merging all columns into one and using binary ops to store data. I'd say you should wait until these three are done cause you'll have major patch re-rolling to do if you create a patch on the current release.
Comment #2
vito_swat commentedOk. I'll wait for your changes.
I think you are right we do not need to pass vid to parsers. Having it in feed will be enough.
To cover custom XML with 2 or more vocabularies case we'd need select list or checkboxes instead of dropdown to allow connect feed items with more than one vocabulary. And we than need to pass somehow list of vocabularies to parser. Personally I wouldn't bother such complicated case. I don't see real usage and it complicates things a lot.
As upgrade path I will keep those per feed type vocabularies. It's site owner thing to clean up if (s)he wants. So in upgrade we only need to connect feed object with a proper vocabulary if it exists. In install file we should add "feed categories" vocabulary for people who start using aggregation. I think it's a clean solution, because it's not breaking current functionality. We don't need to think "merge or not to merge", let's admin decide, as merging is only click-through any feed object to correct vocabulary.
BTW. I received your email. I have to rethink your offer (and reschedule my current tasks to have more time to spent on this project).
Comment #3
vito_swat commentedChanging it to cast as global fefactoring is currently done.
Comment #4
Ashraf Amayreh commentedI believe this has been finished long ago