Part of the reason it took me so long to get to this point with InkLog is because I wanted to make certain I had the design for one part in particular (the dispatcher) done right. I finally gave up on that idea and just pushed it together as fast as I could hoping that, after using it, I would either like it, or think of a better way.
Well, today, I added preliminary XMLRPC support to InkLog. Of course, this is handled through the dispatcher as well. And as far as that goes, the system is pretty simple. I make a single location respond with a template that looks like this:
{xmlrpc->processRequest}
Then the XML-RPC model does the work. Writing the model was easy. Getting it to plug into the dispatcher was a breeze. However, informing the dispatcher of where the XMLRPC template should be executed, while being easy, was less than ideal. I did it by simply adding a template named index with an output type of html at the path /xmlrpc. I just don’t like the way that works.
I don’t like it because, I had to name the output type html. This could be correct by using the (currently unwritten) config framework to inform the dispatcher that the default type for the /xmlrpc path is xmlrpc. Then, I could add a template named index with an output type of xmlrpc with the above data in it. That would work much better, but it leads me to believe that there might be a better way. So I’m asking for help.
The relevant portion of the dispatcher code (which is mostly comment to help clarify what is going on) is this:
function setRequest($pi) {
// Break up the path into pieces
$parts = explode('/',$pi);
// parse the Request.
//
// This will return a 3 element hash
// containing:
//
// 1) the path up the node
// that contained an output type
// (represented by a "." in that path
// portion.
//
// 2) the output type determined by
// what is found after the "."
//
// 3) the remainder of the path
//
// In the event that a "." is not found,
// a default output type will be returned
// the entire path will be returned as
// the node path and the remainder of the
// path portion will be blank.
//
// This should be done better
$req = $this->parseRequest($parts);
// recursively search for the node.
//
// This will start with the longest
// possible path and continue to
// shorten it to locate an
// existing node. The allows
// nodes to utilize additional
// path information for their
// own purposes.
//
// If a match is not found, false will be
// returned.
$node = $this->nodeExistsRecursive($req['node']);
// Set our template name to 'node'
// if a node was found. If not,
// set it to 'index'.
if($node !== false) {
$this->env['node'] = $node;
$tplname = 'node';
} else {
$this->env['node'] = '';
$tplname = 'index';
}
// recursively search for a template file.
//
// Works just like the node search, only
// for template files.
$tmpl = $this->tmplExistsRecursive($req['node'], $tplname, $req['otype']);
// If a template wasn't found, we set it, by
// default to 404error.html which may or
// may not exist.
if($tmpl !== false) {
$this->env['tmpl'] = $tmpl . '/' . $tplname . '.' . $req['otype'];
} else {
$this->env['tmpl'] = '/' . '404error.html';
}
$this->env['pi'] = $req['pi'];
$this->env['orig_pi'] = $pi;
return true;
}
Can anyone come up with some suggestions/ideas for a better way to handle this lookup functionality? Please refer to the CVS respository if you need more code and feel free to ask any questions that might help you understand better.