Hi,
I'm currently writing an application that handles RSS and Atom feeds. I have a bit of a conceptual problem though, and that is how I should encapsulate the different parsers, and the objects they emit, so that I can present a unified interface to the rest of my program.
Is there a common solution to this type of problem? Is there an elegant way to wrap similar-but-differing parsers that emit similar objects?
I've been reading a lot on Design Patterns, OO and such stuff lately, but all that is either too abstract, or I can't see how to apply it to this situation.
I'd appreciate tips, pointers to tutorials or CPAN modules that could help me in this.
Here's a more detailed description of the situation I'm in.
There doesn't exist one single parser for the different kinds of feeds, so I'm using XML::RAI to parse RSS feeds, and XML::Atom::Feed to parse Atom feeds. My own "parse" routine is now an if/else tree like this:
sub parse {
my ($xml, $type) = @_;
if($type eq 'RSS') {
return parse_rss($xml);
}
elsif($type eq 'ATOM') {
return parse_atom($xml);
}
else {
# we don't know what this is,
# so we try each in turn
return parse_atom($xml) || parse_rss($xml);
}
}
sub parse_atom {
my $xml = shift;
my $parser = XML::Atom::Feed->new(\$xml
# lots of code specific to XML::Atom::Feed
}
sub parse_rss {
my $xml = shift;
my $parser = XML::RAI->parse($xml);
# lots of code specific to XML::RAI
}
Ugly. Clumsy.
Then there's the issue with the objects these parsers emit: each one returns their own specific Feed object; each has a method to get at the items, which are objects specific to each parser. I'd like to be able to represent those in a unified way, so that my application doesn't have to worry about the underlying types.
Right now I have resorted to making my own Feed and FeedItem objects (using Class::Accessor), which I populate in the parse_atom and parse_rss subs. But this feels cumbersome, and it looks ugly to me.
Thanks!
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Thanks for the feedback guys.
Dave, nice to see you're still around :)
I kinda like your approach. It was quite a stroll through the CPAN maze to put the pieces together (why don't you bundle up your plugins?), but it looks pretty straightforward.
The only thing is that I have to deal with multiple levels of objects, which makes setting up proxies a bit more complicated. Each parser emits a Feed object, but that feed contains a collection of Entry (in the case of XML::Atom) or Item objects. These items contain largely the same kind of data (title, link, summary, author), but they have different methods. In the case of XML::Atom, the author thing is an object again, whereas for XML::RAI it's a simple string.
Maybe I'm suffering from the compulsion to over-abstract, I don't know. It made me wonder if there's any way to bend an interface into a shape of my choosing. Maybe I need to take a long hard look at Email::Abstract to see how they've handled that.
I've been doing some thinking on this, and I may have an idea.
What I really want is for those parsers to have identical API's, since they perform such similar tasks. So instead of wrapping them in code of my own, I thought I might just inject new methods in them:
*XML::Atom::Feed::parse = sub {
my ($class, $xml) = @_;
return $class->new(\$xml);
};
Now I can do something to the effect of
%parsers = (
RSS => 'XML::RAI',
ATOM => 'XML::Atom::Feed'
);
my $parser = $parsers{$type}->parse($xm
I'd still need the 'unknown' case, but that will be simple with something like ozo showed.
I'd have to do this for more methods, and for the item objects they return, but I think this will save me from having two parse_atom and parse_rss methods that are almost identical.
Is there anything to be said for or against this approach?
Business Accounts
Answer for Membership
by: davorgPosted on 2005-03-07 at 09:31:31ID: 13478447
You might like to take a look at what I do with AudioFile::Info and its plugins. This puts a consistant API onto a whole range of MP3 and Ogg Vorbis processing modules. The basic approach is that in the AudioFile::Info->new method I work out which type of file I'm dealing with and return an object of the correct plugin type. The plugin object basically convert the AudioFile::Info API to the API of the underlying module.
It's a bit like how DBI/DBD works, but _much_ simpler :)
Dave...