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.