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.