There are many Web sites that provide content useful for syndication and distribution to other sites, including Builder.com and TechRepublic.com. Both sites have also recently launched their own RSS (Really Simple Syndication) feeds, which allow Web developers to incorporate content into their own sites.
Creating the RSS feed is one thing; delivering it for everyone to use is a different matter. In this article, we'll examine a solution that will help you deliver your RSS feed to other Web sites quickly and easily.
RSS refresher course
If you are already familiar with RSS, you may want to skip ahead. If not, keep reading to understand the particulars of what RSS is.
Put simply, RSS is an XML grammar for describing syndicated content. Content, of course, is a broad and ambiguous term. For our purposes, we'll define content as articles published on a news Web site. For example, both Builder.com and TechRepublic.com are technology content resources. These sites provide content in the form of articles, which can be syndicated and distributed to other sites. The RSS XML grammar describes the article headlines and descriptions and provides information about how to link back to the full content.
RSS XML documents consist of definitions. At the top level is the channel. Each content item, or article, in the RSS feed belongs to a channel. Often, an RSS feed will consist of a single channel containing all of the articles. The channel contains information such as the title and description, images of the content source, and a link back to the source. Listing A shows an example of the Builder.com RSS feed.
The Java-Java two step
There are two components to serving up the feed to other Web sites. The immediate component answers the question of how to deliver the content to end users. The additional component answers the question of how to create what is delivered to the end users.
Serving it up
An additional requirement for our feed was that it be parameter driven. There are three parameters that can be specified for this page:
Table A: Feed parameters
The feed indicator is used to instruct the page whether to use the Builder.com feed or the TechRepublic.com feed.
If you skim the code, you'll notice a couple of things. First, I've defined a local class inside of the JSP page. The reason behind this is two-fold. One, I like to follow some amount of structure and modularity inside my programs. That could be accomplished by having the class outside of the JSP page, as well. So the second reason I did it inside was the requirement that this entire tool be completely encapsulated in a single JSP page.
The next thing you'll notice is that the actual JSP page code is only a few lines long. Essentially, we instantiate the FeedServer class, generate the feed based on the input parameters, and finally output the results.
Walking through it
Instantiating the class does a few things to set the stage. First, it initializes the default values for our parameters. It also sets up our feed definitions. The next thing we do is call the generateFeed() method. We pass in the HttpServletRequest object so that the class can get at the parameters, which are provided in the request URL.
The generateFeed() method creates a new StringBuffer for the output, acquires the parameters, parses the XML document (the RSS feed), and creates the output. The acquisition of parameters performs some basic validation and sets default values when the parameter is not valid. The document parser uses a simple DocumentBuilder to parse the feed based on the URL.
The URL for each feed is actually stored in a HashMap. This allows us to abstract the specific feed URL from the user.
The output creation is also straightforward. There's a small helper method called getElementValue() that is used to extract specific values from the XML document. This method is called multiple times by the createOutputFromXMLDoc() method to get at the data needed to create the rendered output.
Finally, the output is sent back to the user to display in his or her browser.
Caveats and follow-ups
There are several caveats about the approach presented here. One is the use of the local class in the JSP page. After looking at the code and trying to decide the best way to factor it, I ended up leaving it as you see it here. One issue that I struggled with was whether the class should process the request based on discrete parameters, like this:
generateFeed(feedType, nHeads, showDesc)
or to continue passing the HttpServletRequest to the method. From one perspective, it seemed to be highly coupled with the JSP to continue passing the HttpServletRequest. In other words, even if you move the class outside of the JSP, it's still coupled via the servlet interface. However, I also realized that by passing the full HttpServletRequest instead of discrete parameters, it actually decouples it in a different way.
For example, with discrete parameters, I would need to parse them in the JSP before sending them to the class. If I add new parameters (or modify the existing ones), I would need to make a change in both the JSP and the feed parser class. By passing the entire HttpServletRequest object, I can isolate the changes to just the feed parser class. In other words, I shouldn't need to change the JSP page, since all it does is invoke the parser class, send the entire request, and output the results.
As a follow-up, you could use the same code base to create your own RSS aggregator. By simply modifying the class to call multiple RSS feeds and adjusting the HTML output appropriately (probably removing the channel image and links and abandoning the table approach), you could create a nice headline list from multiple sources.