Creating Dynamic Websites with SportPage
$Revision: 1.11 $
Copyright © 2002 Canadian Broadcasting Corporation
Copyright
Sportwire is copyright by the Canadian Broadcasting Corporation. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation. This software is provided without warranty and no promises are implied; use at your own risk. The Sportwire project is hosted at Sourceforge.net and community participation is welcome and encouraged.
$Date: 2002/03/13 18:12:33 $
Abstract
SportPage is the website presentation component of CBC Sportwire, an archiving and query system for XML documents designed for delivering sports newswire services. The SportPage component is a general purpose Jakarta-Velocity web application template framework, similar to but less complex than Apache Turbine.
The latest edition of this document is available online and as a printable PDF file. For more information on SportPage and the CBC Sportwire news system, please visit the Sportwire home page.
Table of Contents
CBC Sportpage is the website presentation component of Sportwire and is primarily designed to deliver the Sportwire news data for the 2002 Winter Olympics website and for the general CBC Sports website.
SportPage was inspired by Apache/Jakarta Turbine. It shares the same Model-View-Controller(MVC) design where website topic areas are defined by the URI, the context can be manipulated based on the URI, and you may create Java classes to be associated to specific URI path points. Unlike Turbine, Sportpage is intended only for public-information websites; there is no concept of a session, no authentication, and, in the current release, database access is via generic JDBC with SQL.
SportPage is designed to meet the following special requirements:
SportPage is designed for read-only access websites under extreme web-traffic conditions; the site must accommodate sustained server loads in excess of 40 simultaneous clients, and serve millions of pages per day. The server must also allow for migration to distributed server architectures.
Must integrate with existing Java servlet infrastructure. The CBC systems use Apache Tomcat with the Apache webserver, running on HP-UX. The News Template system uses javabeans to access news data and formats these through JSP.
Allow multiple independent deployments on the same server hardware, accommodating independent development teams and virtual hosts. The software must allow multiple instances of itself to be applied to completely independent deployments on the same hardware. Olympics configuration or operation must not conflict with Sports, Sports must not conflict with regional news and so forth.
Model-View-Controller pattern where the model may be in a database, dynamically generated or retrieved from static files, the controllers are primarily Java objects and may come from any arbitrary (even off-site) sources, and the views are defined in HTML.
Separation of development into clear casts. Systems administration and deployment must be completely separate from Java development, and both are distinct from web layout, all three distinct from content generation. Journalists do not code HTML, HTML layout artists do not code Java. Java developers do not mess with system init scripts. This is a basic reality of any large webserver project.
Related to the above Controller definition, SportPage had to allow page designers the freedom to incorporate any java object without requiring support from a Java programmer. If some other department is able to provide a basic javabean for access to some data item, incorporating this into the webpages should not involve any java coding and must be entirely contained within the template and configuration files under the designers' control.
Layout and content changes by design and editorial staff must be implemented on the fly, with no intervention from java programmers or system administrators.
SportPage must place no constraints on the presentation layer.[1]
Human oriented presentation. All URI strings must be easily spoken by the on-air people, topic paths must make logical sense in natural language, and no unnatural terms should be visible.
Guaranteed delivery. As the engine of a website for a National Public Broadcaster, the SportPage server must provide graceful recovery for system errors such as loss of database connections, missing files or parser errors. Any error messages seen by the visitor must be seen as branded message pages and not as infrastructure stack traces or other developer messages.
The template system must use “topic oriented” screen templates. While overall layout and page-components may be shared, the interpretation of context-dependent information must be decidable through inspecting the extra path information in the URI. For example, in /olympics/sports/luge the meaning of $standings will point to a different database cache object than it would in hockey.
Maximum re-use of developed resources. Graphic design and layout talent is expensive: Templates need to use generic methods which can be interpreted according to the path context.
Basic support for transforming XML objects into HTML.
Ad-hoc insertion of SQL result sets and XML documents without requiring Java programming. Ideally this should not involve any systems administration involvement.[2]
SportPage must accommodate a development process where the development and staging servers have no hope of emulating the entire web site. Database access and other live-systems feeds must fail gracefully when unavailable.
While several other portal and web application systems can provide these facilities, most notably Jakarta Turbine, no existing package could provide all of these features without carrying other overheads such as authentication and forced sessions support.
This paper is intended for website designers and content authors who are using SportPage to present their work. It is not a SportPage developers' Guide. Unfortunately, using SportPage will require some basic knowledge of Java's object-oriented syntax; you need not be able to code in Java, but you need to understand syntax such as item.attribute, and understand how objects provide access to the attribute values of the object (it's current state) and provide methods which either modify the object state, or retrieve more complex information from the object.
![[Warning]](../images/warning.gif) | The Map is Not The Territory |
|---|---|
SportPage is an open source project. This means a rapid release cycle and an organic architecture that will evolve over time to meet immediate requirements of the sites deploying SportPage servers, and it means aspects of the project such as documentation and unit testing may not be in sync with the actual code. Even the online API documentation may not be 100% current. If you plan to deploy SportPage, do not depend on the online documents. The most reliable map can be generated by downloading the latest release or CVS snapshot from the project home page and then generating the API documentation with the Foreign/genapi.sh script. | |
[1] the relationship between $layout, $page and $index does place a mild constraint on page templates; because directories cause the page variable to be replaced by the index variable, the master layout template must use at least one #parse($page) call, even if that is the only line in the template.
[2] While this was the goal, in practice, the use of the configuration file definitions for SQL objects requires a servlet container reset, and this requires system admin interventions. On-the-fly reloading of the configuration is on the ToDo list.