[WIP][Routing] Extended Expression Language in a routing component

[mgiustiniani]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	none
License	MIT
Doc PR	not yet

• add tests
• add docs
• gather feedback for my changes

A new expression language engine in a routing component can't extended with new custom functions, in my project i need custom function in a route condition.

with this patch and a custom compilerpass in my bundle i can added my custom function (version_compare of php).
this feature work with symfony/routing >= 2.4

class OverrideServiceCompilerPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container){


        $definition = $container->getDefinition('router.default');

        $definition->addMethodCall('setExpressionLanguage',array(new Reference('examplebundle.routing_expression_language')));

    }
} 

a code of examplebundle.routing_expression_language is here:

class NewExpressionLanguage extends ExpressionLanguage
{

    protected function registerFunctions()
    {
        parent::registerFunctions();

        $this->register('compare', function ($version1, $version2, $operator) {
            return sprintf('version_compare(%s, %s, %s)', $version1, $version2, $operator);
        }, function (array $values, $version1, $version2, $operator) {
            return version_compare($version1, $version2, $operator);
        });
    }

}

[lsmith77]

how would one then parse out the relevant headers? ie. how would one then parse the version from a media type?

[mgiustiniani]

a PR support only extension of expression language, after this PR you can inject an expression language service with injected services (ie. request, security.context etc...).

I need this PR for Versioning API with FOSRestBndle. with add version_compare function i can use a routing condition like this:

condition: "compare(request.attributes.get('version'),'1.1', '>')"

a request and context services is initialized by default

[merk]

@lsmith77 seems like that part isnt actually a consideration here. I like the idea of being able to use version_compare in the routing definitions, but that leaves implementing parsing of version headers up to the user (which we could provide in FOSRestBundle)

[mgiustiniani]

i created an experimental bundle for this functionality
https://github.com/mgiustiniani/RestExtraBundle

[fabpot]

This looks wrong to me. It should just be return $this->matcher;.

[fabpot]

Using method_exists() is not great, but it's probably the only way to keep BC here.

I like this PR. Besides my comment, can you add some tests to validate that the router actually works when injecting an expression language?

[mgiustiniani]

Sure!

[fabpot]

Thinking about this a bit more, I think this is not enough. If several bundles wants to add functions, it won't be possible as we are using inheritance here.

Instead, I think we need to create some kind of FunctionProviders that you can register on ExpressionLanguage instances`. That's what I've done in #12006.

[mgiustiniani]

Multiple ExpressionLanguage is a good option but can create conflict with multiple expression language.
Imho, i create an another expression language class (that extend original expression language) with your new features and user can choose a prefer option. is a bad idea?