SportPage expects and provides a small set of template variables. As much as possible, SportPage does not dictate how these variables are used or what value types they may have; technology should serve the application designers, not enslave them.
There is a very small set of variables which must be defined in the WEB-INF/sportpage.conf configuration file. These are primarily concerned with error recovery and index-page handling and were thus hard-coded into the SportPage design. These required values are summarized in table Table 1
The JDBC variables are passed through the the Xalan connection pool and are thus very unforgiving. Typical symptoms of invalid connection variables is a skyrocketing number of requests to open new pool members (yes, this is a bug). The good news is that these variables are never used if you never instance DBCacheBean objects. These required values are summarized in table Table 2
Table 2. JDBC Connection Variables
| variable | description |
|---|---|
| jdbc.driver | Full class name of the driver. |
| jdbc.url | URL format connection string as in jdbc:postgresql://192.168.1.10/sports. |
| jdbc.user | Required userid for JDBC connections. |
| jdbc.passwd | Required password string; be careful, this is in clear text! |
| jdbc.pool.min | SportPage uses the Xalan connection pool classes; this property specifies the minimum number of spare data connections in the connect pool. |
The optional variables can be defined in the WEB-INF/sportpage.conf configuration file, but will assume practical defaults if they are missing. These are primarily concerned with server installation issues. The optional values and their defaults are summarized in table Table 3
Table 3. Optional Configuration Variables
| variable | default | description |
|---|---|---|
| templates.home | webapp home | A comma-separated list of directories to be searched when looking for a template. When template filenames include path info (for example, in #parse(/path/file)), the path is taken as relative to one of these directories. |
| dom.home | webapp home | A single directory to be searched when looking for an XML file. As with the template home, XML files (usually specified by the extra path info) are taken as relative to this location. |
| file.extensions | .html,.hti | A list of extensions used to resolve base URI's; this list is searched in order until a page is found, and can be set to a different list for different topic contexts. |
| mru.period | 120 seconds | An integer value for the number of seconds between each sweep of the MRU Cache. |
| mru.timeout | 120 seconds | An integer value for the number of seconds that items will persist in the MRU Cache. |
| ttl.period | 120 seconds | An integer value for the number of seconds between each sweep of the TTL Cache. |
| ttl.timeout | 120 seconds | An integer value for the number of seconds that items will persist in the TTL Cache. |
| dbcache.period | 120 seconds | An integer value for the number of seconds between each refresh of JDBC result set DBCacheBean objects. |
| default.timezone | Mountain Standard Time | The ISO timezone code for the zone used to compute local server time for the page calendar object. |
Table Table 4 describes all variables provided by the SportPage page handlers. When adding new dot-variables to SportPage, using these variable names will not be trapped, but may have unexpected results. For more information on the methods and attributes of the built-in objects, consult the Sportwire API Javadocs
![[Tip]](../images/tip.gif) | Per-topic Page Handlers |
|---|---|
The PageHandler classes in the table are the base classes; to assign a specific pagehandler to a path, subclass a parent handler naming it after the right-most general path element, for example, to assign a DOMPageHandler to /olympics/sports/*/legends (all legends pages), you would subclass it as LegendsPageHandler. In practice, page handlers turned out not to be as useful as simply defining new Java Beans in the configuration file, and creating beans that followed the SportPage getInstance API. | |
Table 4. Template Variables
| Variable | Definition | |
|---|---|---|
| $req | HttpServletRequest handed to the current thread of the SportPageServlet; this object can be queried for the state of the request (see the Java Servlet (JSDK) documentation) | |
| $res | HttpServletResponse handed to the current thread of the SportPageServlet; this object can be manipulated to cause HTTP redirects or to issue error codes. | |
| $requestURI | String value with the raw request URI. | |
| $mru | MRUCacheMap is the application-scoped map of objects which will persist only if referenced within the default timeout value specified in the WEB-INF/sportpage.confby mru.timeout.; items are removed after a timeout unless the item lease is renewed by another request for this data. This caches most-recently-used items and allows less popular items to fade from the cache. | |
| $ttl | TTLCacheMap for volatile items; also application-scoped like the MRU cache, only rather than renew objects upon each request, the TTL map will expire all items after the timeout period forcing the server to create new items to replace them. The default timeout value specified in the WEB-INF/sportpage.confby ttl.timeout. | |
| $path | PathBean contains any extra path information beyond the page handler and may be queried in parts to find the depth level or the token at some specific depth. The most common use of this variable is to pull in the rest of the path information as a static file or as a template. Keep in mind that the filename extension may be missing; to get the actual filenam, the extension must be added by using the $path.ext method. | |
| $exception | If not false, this is set to a Java Exception object that can be queried to find out what went wrong. The variable is initialized to false to allow direct if ($exception) tests. | |
| BasicPageHandler | $date | VelocityCalendar A wrapper around the normal Java Calendar class to provide access methods more friendly to Velocity. |
| $page | String containing the filename of the main content area template. This page component is fixed so that SportPage can substitute other page templates, for example, to indicate a sub-page 404 or other error, or to swap in the XML-format template when the file suffix ends in XML. | |
| $topic | String representation of the path in a Java package format (dot-delimited list of path elements); this value can be used by the application to store or fetch items based on a topic.subtopic key. | |
| $indexpage | A flag value set to “t” if the current path describes an index page. If a page is an index page, SportPage will copy the *.index template filename in place of the normal *.page main content template. | |
| $javabeans | BeanFactory to enable pages to load and access instances of any arbitrary Java class. When called as $javabeans.getBean(classname) and given the fully-qualified package name for any reachable java class, the new class is inspected for a SportPage-specific getInstance(context) factory method, then for a null getInstance() and finally for a null constructor. | |
| $params | ParameterParser is adapted from Jakarta Turbine. This is a java Map object populated with GET/POST and/or PATH_INFO parameters. Access methods provide type-safe ways to get at java primitive types (getBoolean, getBigInteger...) The big advance here is with JavaBeans. This class allows you to set bean properties with one call just as you would normally do in JSP: $params.setProperties( $mybean ) | |
| $xml | DOMFileFactory for processing XML files; the actual Java class returned is specified in the dom.data.class property and defaults to creating JDOMFile objects. XML documents returned by the $xml.dom(filename) call can be queried, transformed or output as XML text. (see Sportwire JDOMFile API Docs) |
The easiest way to add new facilities to SportPage is to declare new objects using the topic.*.bean dot-variables. This facility allows you to add objects in much the same way as you would add java beans to JSP pages. The most flexible way to add new services, is to create Java classes or wrapper classes which follow the SportPage bean API; this allows for beans which are singleton instances, store an application-scoped instance in the global property map, or to cache instances based on the path info or other context values.
When invoked from the WEB-INF/sportpage.conf, BeanFactory will attempt the load the specified java class via the following sequence:
getInstance(ExtendedProperties) passing the application-scoped property list ($global)
getInstance()
a no-parameter constructor
SportPage includes several general utility bean objects for reading XML or database objects or for wrapping useful Java library objects in a Velocity-friendly package. For full details on these classes, visit the http://sportwire.sourceforge.net/api/ca/cbc/sportwire/servlet/data/package-summary.html