1. 06 Jun, 2014 1 commit
    • Fabien Potencier's avatar
      minor #941 Change the order of routes. (ifdattic) · 75b8714f
      Fabien Potencier authored
      This PR was merged into the 1.0 branch.
      
      Discussion
      ----------
      
      Change the order of routes.
      
      The note below suggests adding more generic routes at the bottom
      as the first matching route is used.
      
      In my opinion the code block should also follow this suggestion
      as it makes more clear how to use routes.
      
      Commits
      -------
      
      a1a61fd1 Change the order of routes.
      75b8714f
  2. 15 Apr, 2014 1 commit
  3. 07 Apr, 2014 1 commit
  4. 06 Apr, 2014 1 commit
    • Andrew M's avatar
      Change the order of routes. · a1a61fd1
      Andrew M authored
      The note below suggests adding more generic routes at the bottom
      as the first matching route is used.
      
      In my opinion the code block should also follow this suggestion
      as it makes more clear how to use routes.
      a1a61fd1
  5. 20 Jan, 2014 2 commits
  6. 08 Jan, 2014 2 commits
  7. 03 Dec, 2013 2 commits
    • Fabien Potencier's avatar
      minor #879 Remove gendered pronouns (epochblue) · 53b9381b
      Fabien Potencier authored
      This PR was merged into the 1.0 branch.
      
      Discussion
      ----------
      
      Remove gendered pronouns
      
      When referencing hypothetical users, it's more inclusive to use
      gender-neutral prnouns. Instances of he/she/his/her/him have been
      replaced with they/them/their and verb tenses changed to match.
      
      Commits
      -------
      
      c48da4ca Remove gendered pronouns
      53b9381b
    • Bill Israel's avatar
      Remove gendered pronouns · c48da4ca
      Bill Israel authored
      When referencing hypothetical users, it's more inclusive to use
      gender-neutral prnouns. Instances of he/she/his/her/him have been
      replaced with they/them/their and verb tenses changed to match.
      c48da4ca
  8. 30 Oct, 2013 2 commits
  9. 23 Sep, 2013 4 commits
  10. 08 Sep, 2013 2 commits
  11. 04 Sep, 2013 1 commit
  12. 09 Aug, 2013 2 commits
  13. 04 Jul, 2013 3 commits
  14. 03 Jul, 2013 3 commits
    • Fabien Potencier's avatar
      8fc77c27
    • Fabien Potencier's avatar
      merged branch luisgonzalez/1.0 (PR #707) · 51622a78
      Fabien Potencier authored
      This PR was merged into the 1.0 branch.
      
      Discussion
      ----------
      
      add '_route' key to RedirectableUrlMatcher::redirect
      
      When there is a logger, the Symfony\Compoment\HttpKernel\EventListener\RouterListener::onKernelRequest method expects the '_route' key to exist in order to log the matched route and issues a PHP Notice
      
          <?php
          date_default_timezone_set('America/Los_Angeles');
      
          require_once __DIR__ . '/../vendor/autoload.php';
          Symfony\Component\HttpKernel\Debug\ErrorHandler::register();
          $app = new Silex\Application();
          $app['debug'] = true;
          $app['monolog.logfile'] = 'C:/TEMP/log.log';
          $app->register(new \Silex\Provider\MonologServiceProvider());
          $app->get('/a/', function() {
              return 'done';
          });
      
          $app->run();
      
      *[url]/a* issues the notice before redirecting to */a/*
      
      Commits
      -------
      
      3d1a868c add '_route' key to RedirectableUrlMatcher::redirect
      51622a78
    • Fabien Potencier's avatar
      merged branch igorw/cookbook-fatal (PR #735) · a7a7ef41
      Fabien Potencier authored
      This PR was merged into the 1.0 branch.
      
      Discussion
      ----------
      
      Add note on how to handle fatal errors
      
      I'm not so happy with this solution from a usability perspective, but I don't want to have global error handlers in silex itself.
      
      An option we could consider is making symfony's ErrorHandler fall back to an internal ``ExceptionHandler`` for fatal errors. But obviously that is not very elegant either. Ideas welcome.
      
      Commits
      -------
      
      7a222ce5 Add note on how to handle fatal errors, as per mailing list
      a7a7ef41
  15. 30 Jun, 2013 1 commit
    • Fabien Potencier's avatar
      merged branch hhamon/phpdoc (PR #738) · 2ba7d326
      Fabien Potencier authored
      This PR was merged into the 1.0 branch.
      
      Discussion
      ----------
      
      Fixed typo in the ServiceProviderInterface interface PHPDoc block.
      
      Commits
      -------
      
      8bf3f788 Fixed typo in the ServiceProviderInterface interface PHPDoc block.
      2ba7d326
  16. 29 Jun, 2013 1 commit
  17. 24 Jun, 2013 1 commit
  18. 19 Jun, 2013 2 commits
    • Fabien Potencier's avatar
      merged branch TomAdam/pr-update-middleware-doc (PR #725) · d8776876
      Fabien Potencier authored
      This PR was submitted for the master branch but it was merged into the 1.0 branch instead (closes #725).
      
      Discussion
      ----------
      
      Alter app references in middleware doc
      
      I use ControllerProvider's and functions for my controllers, and I rely on the ````Application```` and ````Request```` being injected via the parameters of each function. Today I happened to need to build some middleware, but found that ````public function before(Application $app)```` resulted in a fatal as the middleware does not use type hinting to set parameters like controllers do. On digging a bit deeper I found in ````Silex\EventListener\MiddlewareListener.php::onKernelRequest```` the following line:
      ````
      $ret = call_user_func($callback, $request, $this->app);
      ````
      This injects application as the second parameter. I'm really happy that it does do this, but the parameter order seems a little strange to me. It's a bit at odds with the rest of the documentation on controllers - the general method prototype is ````method(Application $app, Request $request)````. Given this, I would have expected the app to come first in the parameter list. The same applies to the after callback, except it has ````Response```` between ````Request```` and ````Application````.
      
      The global middleware defined in ````Application```` do not inject the app in any of the callbacks, confusing the matter further. My pattern doesn't actually require this, but some people's might. Is there a reason this hasn't been done? It would be very simple to add, given the three methods are inside the ````Application```` class itself.
      
      The ideal fix to this would be that the middleware use type hinting to apply the parameters, but this is complicated by the callbacks occurring in two classes, neither of which are local to the existing type hinting code. At the very least I think this functionality should be documented, so this is what I have provided in the PR.
      
      Commits
      -------
      
      ddc9b92 Alter app references in middleware doc
      d8776876
    • Tom Adam's avatar
      Alter app references in middleware doc · 120bfa9a
      Tom Adam authored
      120bfa9a
  19. 06 Jun, 2013 4 commits
  20. 16 May, 2013 1 commit
  21. 08 May, 2013 2 commits
  22. 07 May, 2013 1 commit