Silex/Symfony components support

[glaubinix]

Good evening,

I really like the way this changes how you build your application, especially the part about not injecting the Container everywhere. The solutions to the problems look really elegant. The same issues you solve appear in almost all Silex applications as well as you get the Application and Request object injected into every controller action.

If you currently want to use this package in your non symfony fullstack application you are still forced to install the symfony/framework-bundle. To avoid this would it either be possible to remove the dependency and transform it into a suggest or extract the reusable components into a separate package? I would be happy to help with any of the 2 options or if you have another idea.

[beberlei]

@glaubinix Sorry for the late reply, a suggest would be OK. I would prefer not to maintain the Silex code myself though, since we don't use silex.

[glaubinix]

@beberlei no worries. I'll PR the change later this week and will tackle the silex part once the Pr is done.

[beberlei]

@glaubinix Actually just today a silex requirement came up :)

[glaubinix]

@beberlei nice. To be honest the silex part should not be too much work because most of it is simply EventListener registration in silex providers.

[beberlei]

@glaubinix Do you have an idea how return array() in a controller would resolve the template name?

[glaubinix]

@beberlei not sure I fully understand what you mean.

By default it wouldn't resolve a template name.. Isn't this what the ViewListener with the Guesser is for? Via HttpKernel the same Event is triggered in Silex. Do you want to know how the guesser would work?

[beberlei]

@glaubinix Yes thats what the guesser is for, but what to guess when you just have a closure, no function name, no route name :-)

$app->get('/hello', function () { return array(); });

I guess we can only make this work when you use ControllerProvider and object callbacks as routes, i.e.

 $controllers->get('/', array($this, 'helloAction'));

[glaubinix]

@beberlei well, every route has a route name even a closure, so something like:

$app->get('/t', function() {
    return [];
});

Request::attributes::parameters['_route'] => 'GET_t';

Also as soon as you use the UrlGenerator, I kind of have to name routes because otherwise you cannot use your route definitions to generate urls. If you do this:

$app->get('/test', function() {
    return [];
})->bind('testroute');

Request::attributes::parameters['_route'] => 'testroute';

[glaubinix]

I started on Friday with the Silex port (https://github.com/glaubinix/silex-no-framework/) and spotted one more issue. In some places the ContainerInterface is used: ControllerUtils, ParamConverter and QafooControllerNameParser.

This is not so much a problem for the ControllerUtils and the ControllerNameParser because they might look a bit different or I wont have to port them.

The main problem is the ParamConverterListener where I have 2 options how to solve it without rewriting the entire Listener. Either I move the Container access to a protected method so I can overwrite it in Silex or inject a wrapper around the container to the ParamConverter which would delegate the calls to either the Symfony Container or the Silex Application (depending on the instance).

Any preferences?

[beberlei]

@glaubinix wrapper

[glaubinix]

@beberlei by now I have most of the functionality available for Silex and I will tag the library as soon as I cleaned up the template guesser So feel free to close this issue if you are not missing anything for your use cases.

I did not port the ControllerUtils class and the TemplateGuesser has no support for closures for now. I think it might be easier to use something like https://github.com/glaubinix/symfony-template-response for closures, which I used in another project already and move to a proper library last week.