All blog entries reflect the opinions of the author and have not been expressly endorsed by the Ivan Allen College of Liberal Arts or the Georgia Institute of Technology.
In my quest to simplify the back-end designs for the new websites I'm building for the Ivan Allen College, I knew early on that I'd have to tackle the handling of news and events. Since the advent of the central Mercury news system, news and events have been traditionally pulled into campus websites in one of two ways:
- Import news and events into nodes using the Feeds XPath Parser, then format the nodes, typically by using Views
- Use the slightly newer 'Turnkey' option that polls Mercury to update a local cache and displays news and events in a standardized row-based format via a Drupal block
The trade-off has been that the first method gives you more programmatic control over the display of news and events (without having to code anything in PHP), while the later is much easier to setup with less overhead, but also with less flexibility in the way news and events are displayed.
Well, I really wanted to get the best of both worlds some way, somehow -- an easy to setup module, but with more display flexibility. I really wanted to keep news and events out of nodes, but I also wanted to speed up the rendering of news and event summaries on my sites' front pages. Taking this all into account, I came up with an unorthodox approach that so far is working really well for me.
The key to this approach is a 'News Translation' service that I built: an almost headless web application that periodically polls the Mercury server and syncs a local database with the Mercury news feeds I've identified as being connected to the college and its various schools and project centers. This translation service does most of the data pre-processing and then makes that ready-to-use data available via JSON feeds. A greatly simplified news-and-events Drupal module installed on the actual public-facing website can then query for that feed and display listings of news or event items, or the detailed full listing for one particular item.
The net result is that on each of our websites I can now run a Drupal module for news and events that has a lot less complex logic in it. The module just implements a few virtual pages and blocks, polls the News Translation server for data, and then generates the content for the requested page or block. The majority of the module's code simply deals with visual formatting of the data, which means that one can work up innovative new ways to display news and events without having to wade through tons of data parsing and processing code. This does require knowing a little something about PHP, HTML, and CSS, but in my humble opinion it's still much easier to work up new display concepts this way than with either of the two traditional methods of pulling in Mercury news and events.
An additional benefit of this system is an increase in rendering speed. Whenever your website has to poll Mercury directly for a data update (such as when the local cache has expired), you're now having to wait for Drupal on the Mercury server to bootstrap, followed by waiting for the feed to be assembled and converted into an XML object. Once your local web server has the XML, it has to go through the task of unpacking the object and walking through it to find everything needed to render its own display of the requested news/event items. With my system, the website is talking to a dedicated PHP application that has far less bootstrapping overhead than Drupal, so it starts up fast and quickly spits out the requested JSON object. JSON is a lot easier for PHP to parse, so with a simple json_decode() call all of the data structures are expanded into a hash array that's ready for rendering into HTML output.
I've added additional efficiency by having the News Translation server embed all of the thumbnail images for any requested news items directly into the JSON feed, so only one HTTP request is needed to retrieve all related data, no matter how many attached images your news items might have. I then provide that image data inline in the final HTML output (embedding it into IMG tags), so that the client web browser doesn't have to make multiple HTTP requests for the thumbnails either.
My first public example of the use of this system is now available at the Center for International Strategy, Technology, and Policy (CISTP) website:
This technique may not be right for everyone, but I'd certainlly recommend it to any college-level web developer overseeing multiple websites that use Mercury news and events. One caveat is that I haven't packged up the code for my News Translation service just yet (one of these days, once I get some other stuff off my plate), but for now I wanted to share the concepts behind what I'm doing to help others start to think a little more outside the box.