- 30 Jun, 2012 2 commits
- 29 Jun, 2012 1 commit
-
-
Fabien Potencier authored
-
- 28 Jun, 2012 2 commits
-
-
Fabien Potencier authored
-
Fabien Potencier authored
Commits ------- 32ca5b51 Do not care about `mailer` service changes efd3757d Avoid Swift Mailer initialization if possible Discussion ---------- Avoid Swift Mailer initialization if possible 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.
-
- 27 Jun, 2012 2 commits
-
-
Slavi Pantaleev authored
Until now we tried to detect `mailer` service changes, and always flushed messages for them, just to be safe. To keep things simple, we don't do this anymore. If `mailer` gets replaced by another service, flushing will fail as expected. People should not replace it.
-
Fabien Potencier authored
-
- 26 Jun, 2012 4 commits
-
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
- 25 Jun, 2012 10 commits
-
-
Fabien Potencier authored
-
Slavi Pantaleev authored
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.
-
Fabien Potencier authored
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
-
Dave Marshall authored
-
Fabien Potencier authored
Commits ------- 14da2873 Typo in security docs Discussion ---------- Typo in security docs
-
Igor Wiedler authored
-
Fabien Potencier authored
Commits ------- 7ef0e3a4 Correct key name in example Discussion ---------- Correct key name in WSSE example docs
-
Dave Marshall authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
- 23 Jun, 2012 7 commits
-
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
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.
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
- 22 Jun, 2012 7 commits
-
-
Igor Wiedler authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
-
Fabien Potencier authored
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.
-
- 19 Jun, 2012 5 commits
-
-
Dave Marshall authored
-
Fabien Potencier authored
Commits ------- 47769119 Update ControllerProvider example to use the controllers factory Discussion ---------- Update ControllerProvider example to use the controllers factory
-
Romain Neutron authored
-
Fabien Potencier authored
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! -
Fabien Potencier authored
-