The BasicPageHandler adds several dot-variables to the context before the configuration variables are parsed. These include a VelocityCalendar set to the current time, an application-scoped keyword/value map, and utility objects for fetching database and xml items, and for creating arbitrary java objects.
The BasicPageHandler creates a $date variable that defaults to Mountain Standard Time ... this can be set to any valid timezone code using the timezone property ... and yes, if you want to get perverse, you can set different time zones for different topic areas (ie sports.bobsleigh.history.timezone=PST)
SportPage also supports preloading of Javabeans through the configuration file. When dot-variables end in .bean, SportPage will interpret the value as the String value of the fully qualified class name and create an instance of that class under the variable name. For example, default.now.bean set to java.util.Date will provide a global variable $now containing a Java date object; sports.venue.now.bean would only define this value in the /sports/venue subtopic. (See Section , “Adding Javabeans”)
Suppose you have a large collection of XML objects that may or may not be read into sections of pages throughout the site. It would be highly inefficient to have these objects all preloaded, and too awkward and clunky to load and parse each of them on every request; the general pattern of use for such items are that a small set will be used frequently, and the most recently used are the most likely to be requested by subsequent visitors to the site. This latter rule is especially evident with news sites where the resource describes some topical event.
The SportPage solution is a “most-recently-used (MRU) time-to-live (TTL) cache map”, a global lookup table matching item requests to the objects requested, but where inactivity will cause an object to be removed from the cache after some pre-set time lapse. The refresh is such that the next edition is loaded and then stored, so previous objects that are still in scope are still valid for template display. It's kind of like the afterimages you see watching moving objects while on acid: The data item you get may be a few seconds stale, even while the new one is loading.
For example, given the URI /fencing/legends/damocles which expects to be rendered through fencing.legends.page set to the template /fencing/legends.vm, the template begins with the line
$bio = $xml.dom($path)
$bio now contains the JDOM object.
The $xml object uses the expiring TTL cache map, and in the above case, it sees a call to dom( "/fencing/legends/damocles.xml" ) which it finds in $dom.home/fencing/legends/damocles.xml and retains until the association times out. This allows the XML file to be re-parsed for the subsequent calls while handling peak bursts of site activity.
SportPage also provides a renewing MRU cache map for retaining static or self-renewing items such as database result sets. These objects stay in the map so long as they are used and start to expire only after the most recent access.