The finish() filter flushing spool messages after each request
caused Swift Mailer to be initialized and all services in this
provider to be instantiated.

Doing all this work takes time and is potentially unnecessary,
since only a small number of all requests queue messages for sending.

The time it takes to initialize swiftmailer and all services is between
1 and 2ms on the 2 machines I tested on.
This seems like a big price to pay for just including a provider
that does nothing for most requests.

Commits
-------

2a3bb653 Tie configs to firewall name to ensure correct exception listener is used

Discussion
----------

Tie configs to firewall name to ensure correct exception listener is used

Without this, the last declared firewall's exception listener is used for all firewalls

Commits
-------

14da2873 Typo in security docs

Discussion
----------

Typo in security docs

Commits
-------

7ef0e3a4 Correct key name in example

Discussion
----------

Correct key name in WSSE example docs

Commits
-------

33061c8f Recommend composer in README

Discussion
----------

Recommend composer in README

Side note: Please update http://silex.sensiolabs.org/download to use 1.0.* instead of dev-master.

Commits
-------

e408ca41 Pulled standard auth mechanisms in to extendable factories

Discussion
----------

Pull standard auth mechanisms in to extendable factories

I'm not really too sure about this implementation myself, but it got me where I needed to be, in that I can define a factory for a custom authentication provider and list the type in the firewall config, something like this:

``` php
<?php

$app['security.firewalls'] = array(
    'api' => array(
        'pattern' => '^/api',
        'wsse' => true,
        'anonymous' => true,
    ),
);

$app['security.authentication.factory.wsse'] = $app->protect(function ($name, $options) use ($app) {
    $app['security.entry_point.wsse.'.$name] = new WsseEntryPoint(...);
    return array(new WsseListener(...), 'wsse');
});

```

I can't see any particular use case for overriding the standard factories (particularly because the _proto functions are there to override) but they are there if someone comes up with one, and it seemed to make things neater in the block building the firewall map.

I've got enough here so that I can move on with my project, if this approach is good enough, I can refine it as necessary, if not, any guidance would be appreciated and I'll work on something better.

Commits
-------

47769119 Update ControllerProvider example to use the controllers factory

Discussion
----------

Update ControllerProvider example to use the controllers factory

Commits
-------

63e660fa added more docs
acf60818 added some unit tests
72ac7c5a merged the render and stream method of TwigTrait
a439ae7f added traits for the routes
3266c735 added application traits for PHP 5.4

Discussion
----------

PHP 5.4 support

This is a first attempt to provide useful shortcut methods on the Application class via traits. It also contains a `secure` method for routes.

Here is how you can make use of these features on PHP 5.4:

    use Silex\Application;
    use Silex\Route;

    class MyApp extends Application
    {
        use Application\TwigTrait;
        use Application\SecurityTrait;
        use Application\FormTrait;
        use Application\UrlGeneratorTrait;
        use Application\SwiftmailerTrait;
        use Application\MonologTrait;
        use Application\TranslationTrait;
    }

    class MyRoute extends Route
    {
        use Route\SecurityTrait;
    }

    $app = new MyApp();
    $app['route_factory'] = function () use ($app) {
        return new MyRoute();
    };

This PR depends on #376.

And here is a sample controller using the traits:

    $app->get('/{name}', function(Application $app, Request $request, $name) {

        $app->mail(\Swift_Message::newInstance()
            ->setSubject('[YourSite] Feedback')
            ->setFrom(array('noreply@yoursite.com'))
            ->setTo(array('feedback@yoursite.com'))
            ->setBody($request->get('message')));

        $app->log('Foo Bar');

        return $app->render('hello', [
            'name' => $name,
            'url'  => $app->url('home', ['name' => 'Fabien']),
            'user' => $app->user(),
        ]);
    })
    ->bind('home')
    ->assert('name', '\w+')
    ->secure('ROLE_ADMIN') // <- method defined in Route\SecurityTrait
    ;

As you can see, it makes things much more readable and easier to understand. And of course, it makes Silex very flexible as you can add any method on Application and Route. You just need to define a trait and register it on your custom Application or Route.

---------------------------------------------------------------------------

by fabpot at 2012-06-17T15:32:15Z

Another option to avoid having to override the route factory is to define a parameter for the route class:

    $app['route_class'] = 'MyRoute';

Most of the time this should be sufficient.

---------------------------------------------------------------------------

by fzaninotto at 2012-06-17T16:56:59Z

VERY readable. This change makes Silex even better. Great idea!

---------------------------------------------------------------------------

by mrmark at 2012-06-18T17:42:57Z

This is really awesome!  Really shows off the power of traits.

I was trying out Silex a while ago, and I wanted to try to extend the Silex\Application class, but this sort of broke down at the [Silex\ControllerProviderInterface](https://github.com/fabpot/Silex/blob/master/src/Silex/ControllerProviderInterface.php#L28) because it expects the Silex\Application class.  This means that IDE's and the like wouldn't know about any new methods in my new class.  This is probably more important now with this PR because the IDE wouldn't know about any of the traits used.

---------------------------------------------------------------------------

by stof at 2012-06-18T17:46:55Z

@mrmark There is nothing we can do for it. We cannot document the doc by mentioning your own application class. It would be wrong as the silex application class is valid, and it would be impossible as your own application class is not part of silex.

---------------------------------------------------------------------------

by mrmark at 2012-06-18T18:17:20Z

@stof Sorry, I wasn't suggesting that Silex be modified to accommodate my application class specifically.  I'm not actually sure of the solution here, perhaps change the interface to look like so:

    public function connect($app);

And then depend upon the PHPDoc to tell the IDE what $app really is?  In the end, it would be nice if we knew what $app really was so we would know what methods and the like are available.

---------------------------------------------------------------------------

by stof at 2012-06-18T18:19:20Z

@mrmark the issue is the same: the phpdoc is still in the Silex code. And removing typehints just because inheritance is allowed is wrong IMO

---------------------------------------------------------------------------

by fabpot at 2012-06-19T07:51:38Z

I've just added a bunch of unit tests for the new traits. Any other thoughts before I merge?

---------------------------------------------------------------------------

by GromNaN at 2012-06-19T08:05:22Z

Trait tests should be skipped for PHP < 5.4

---------------------------------------------------------------------------

by fabpot at 2012-06-19T08:07:38Z

@GromNaN That's already the case.

---------------------------------------------------------------------------

by igorw at 2012-06-19T11:17:26Z

👍 Ship it!

Commits
-------

030713de Monolog class is configurable

Discussion
----------

Monolog logger class is configurable and accessible

As an alternative to #379

---------------------------------------------------------------------------

by igorw at 2012-06-18T13:43:36Z

👍

Commits
-------

c463a6e1 added some unit tests
e29c91ed added an exception when a method does not exist to ease debugging
3fd92830 made controller methods (before, after, ...) extensible

Discussion
----------

made controller methods (before, after, ...) extensible

You can now add your own methods on controllers (like the built-in
after, before, convert, ...) by defining your own Route class:

    class MyRoute extends Route
    {
        public function secure($roles, $app)
        {
            // do something
        }
    }

and then change the "route_factory" accordingly:

    $this['route_factory'] = function () {
        return new MyRoute();
    };

If you want to benefit from the new methods in a custom controller
collection, pass an instance of your Route to the ControllerCollection
constructor:

    $controllers = new ControllerCollection(new MyRoute());

or even better, use the "controllers_factory" service:

    $controllers = $app['controllers_factory'];

The limitation is that you can only have one custom Route class in an
Application. But this PR is just the first step. Thanks to PHP 5.4 and
the new traits support, the next pull request (#378) uses this new
refactoring to provide traits that you can add to your
custom Application Route class.

---------------------------------------------------------------------------

by igorw at 2012-06-18T12:13:33Z

Looks good to me. One thing, what about a method_exists() in `__call` to give a better error message?

---------------------------------------------------------------------------

by fabpot at 2012-06-18T17:41:34Z

I've added an exception for when the method does not exist.

---------------------------------------------------------------------------

by fabpot at 2012-06-18T18:03:00Z

And now with some unit tests.

---------------------------------------------------------------------------

by igorw at 2012-06-18T18:33:33Z

👍