Re: Jamaica Request Mapper

One reasonable point of departure for developing the mapper, given that 
we want to use what is already there to the extent possible, is to begin 
  looking at how to enhance the xarRequest object.

This object up to now has been a sort of backwater of the core :)
It is used for mainly its getInfo() method and in a couple of cases its 
getVar() method. Faced with a request mapper, the functionality needs to 
be cast more generally to take into account short urls and potentially 
more exotic request types.

As a consequence of this, the idea presents itself to pass to a 
hypothetical mapper not information returned by the request object, but 
the object itself. This gives us more flexibility in the types of 
requests we'll be passing.

This however means creating instances of the request object. At present 
iirc all the core objects just run static methods, so this would sort of 
break that mould, and in doing so we open the door to a more 
differentiated OO code in the core.

With increased use of instances in turn the idea of lazy loading for 
performance gains in importance. That means more sys::inport lines, 
scattered in the codebase.

Luckily php5 has the __autoload function which can make this easier. 
Even without instances, with an autoload function we can save over 60 
lines of code in the core and core modules for the DataObjectMaster 
calls alone.

But in order to have a manageable __autoload function we need to adjust 
the locations, filenames and names of classes into some sort of standard 
schema that can be codified.

So from the idea of a request mapper we have wandered all the way to the 
idea of renaming and restructuring the OO classes :)

That said there will never be a "one size fits all" solution , the 
classes we are using are in too many different diverse locations. But 
surely we can reduce the number of sys::import calls substantially. 
Furthermore such a renaming can be done incrementally over time.

Thoughts?