Changeset View
Changeset View
Standalone View
Standalone View
src/applications/celerity/postprocessor/CelerityPostprocessor.php
- This file was added.
<?php | |||||
abstract class CelerityPostprocessor | |||||
extends Phobject { | |||||
joshuaspence: Maybe add a basic test class as in D13272. I haven't seen these tests catch any real issues yet… | |||||
private $default; | |||||
abstract public function getPostprocessorKey(); | |||||
abstract public function getPostprocessorName(); | |||||
abstract public function buildVariables(); | |||||
public function buildDefaultPostprocessor() { | |||||
return new CelerityDefaultPostprocessor(); | |||||
} | |||||
final public function getVariables() { | |||||
$variables = $this->buildVariables(); | |||||
$default = $this->getDefault(); | |||||
if ($default) { | |||||
$variables += $default->getVariables(); | |||||
} | |||||
return $variables; | |||||
} | |||||
final public function getDefault() { | |||||
if ($this->default === null) { | |||||
$this->default = $this->buildDefaultPostprocessor(); | |||||
} | |||||
return $this->default; | |||||
} | |||||
final public static function getPostprocessor($key) { | |||||
Not Done Inline ActionsI wonder if the "return the default postprocessor" logic should live here? Like, maybe CelerityPostprocessor::getPostprocessor(null) should just return the default. Also, maybe CelerityPostprocessor::getPostprocessor('nonexistent_key') should throw an exception joshuaspence: I wonder if the "return the default postprocessor" logic should live here? Like, maybe… | |||||
return idx(self::getAllPostprocessors(), $key); | |||||
} | |||||
Not Done Inline ActionsI've been wondering if we should make these fields final? This is probably more siginificant if/when we drop PHP 5.2 support and can use late static binding. joshuaspence: I've been wondering if we should make these fields `final`? This is probably more siginificant… | |||||
final public static function getAllPostprocessors() { | |||||
static $postprocessors; | |||||
if ($postprocessors === null) { | |||||
$objects = id(new PhutilSymbolLoader()) | |||||
->setAncestorClass(__CLASS__) | |||||
->loadObjects(); | |||||
$map = array(); | |||||
foreach ($objects as $object) { | |||||
$key = $object->getPostprocessorKey(); | |||||
if (empty($map[$key])) { | |||||
$map[$key] = $object; | |||||
continue; | |||||
} | |||||
throw new Exception( | |||||
pht( | |||||
'Two postprocessors (of classes "%s" and "%s") define the same '. | |||||
'postprocessor key ("%s"). Each postprocessor must define a '. | |||||
'unique key.', | |||||
get_class($object), | |||||
get_class($map[$key]), | |||||
$key)); | |||||
} | |||||
$postprocessors = $map; | |||||
} | |||||
return $postprocessors; | |||||
} | |||||
} |
Maybe add a basic test class as in D13272. I haven't seen these tests catch any real issues yet, but theoretically it means that we will catch issues with two postprocessors having the same key.