Extending the Filter

Extending Particle\Filter leads to some boilerplate code, because of the fact that the filter-rules actually exist as methods on the FilterResource object. This is because we want IDE-supported code-completion. So, in order to write your own rules, you'll need to overwrite two classes: the Filter itself, and the FilterResource.

Overwriting the Filter itself is quite simple:

use Particle\Filter\Filter;

/**
 * @method MyFilterResource value()
 * @method MyFilterResource values()
 * @method MyFilterResource all()
 */
class MyFilter extends Filter
{
    /**
     * {@inheritdoc}
     * @return MyFilterResource
     */
    public function getFilterResource($keys = null)
    {
        return new MyFilterResource($this, $keys);
    }
}

As you can see, it returns a different implementation of the FilterResource object. That's where you can add the new filter-rules to the FilterResource. Luckily, also overwriting the FilterResource itself is rather simple:

use Particle\Filter\FilterResource;

class MyFilterResource extends FilterResource
{
    /**
     * @return $this
     */
    public function grumpify()
    {
        return $this->addRule(new FilterRule\Grumpify);
    }
}

So we've exposed a new public method to the FilterResource: grumpify. However, that filter-rule doesn't exist in the default filter, so we have to build it:

use Particle\Filter\FilterRule;

class Grumpify extends FilterRule
{
    public function filter($value)
    {
        return 'I hate ' . $value . '!';
    }
}

All that's left is actually using your own filter:

$f = new MyFilter();
$f->value('test')->trim()->grumpify();
$result = $f->filter([
    'test' => '  icecream  ',
]);
var_dump($result); // array(1) { ["test"]=> string(16) "I hate icecream!" }

That's that: you can now go wild on adding filter rules. If you think a rule should be added to the main Particle\Filter repository, please create a pull request (or an issue).