The first rule on defining new page handlers is “don't”. In most cases, page handlers we created were later deprecated and replaced with the more flexible topic/context manipulations. There are only two reasons to define a new page handler: Special path handling and context manipulations.

Suppose you need special default handling for the $path (the PATHINFO after the servlet URI) that must occur before any rendering of the page takes place; SportPage includes automatic handling for XML paths, but if you wanted to do something funky with .swf extensions (dynamically generated Flash animations based on real-time data?), this would be a good case for a new page handler.

BasicPageHandler is a good example of the first case: We needed to test the URI path to see if it is a directory, and if so, swap the $index page over the $page variable.

A good bad-example is AthletesPageHandler, originally intended to interpret the path as an XML file, returning the JDOM model for the template to pick apart. We soon realized we'd want general purpose XML everywhere, so there was no need for a special topic (directory path) just for XML. PageHandlers attach the pre-rendering to a path, not to a purpose.

The second reason for page handlers is to be able to fiddle with the context, for example to dynamically change layout pages or other items.

A quasi-bad example of the second reason for PageHandlers is the LineupPageHandler^[4] which was originally used to provide access to the Newsworld presentation template classes used by the CBC to retrieve headlines and stories from their news system. Why a bad idea? The same thing could be done using a property bean and, if they ever want to dump it, they won't need a java programmer.