The silex part of https://github.com/fabpot/Pimple/pull/37

Additional changes contained in this PR:

• disallow adding bootable service providers after the app is booted

This may be merely something to add to the docs.

Using a simple application such as the following:

<?php

require_once __DIR__.'/../silex.phar';
use Symfony\Component\HttpFoundation\Response;

$app = new Silex\Application();

$app->get('/', function () use ($app) {
      return new Response('Home root');
});
$app->get('/hello', function () use ($app) {
      return new Response('No trailing slash');
});
$app->get('/hello/', function () use ($app) {
      return new Response('With trailing slash');
});

$app->run();

this is the observed behavior:

• http://app/ -> caputured by 'Home' route
• http://app/hello -> caputured by 'No trailing slash' route
• http://app/hello/ -> caputured by 'With trailing slash' route

However expected behaviour would be that the last route is inaccessible:

• http://app/ -> caputured by 'Home' route
• http://app/hello -> caputured by 'No trailing slash' route
• http://app/hello/ -> caputured by 'No trailing slash' route

If the last route is not defined, the result of requesting /hello/ is "Sorry, the page you are looking for could not be found." - but you'd expect it to match the routefor /hello.

This is testing on an arch linux machine running nginx - though that shouldn't really be much of a factor.

The section running tests in about https://github.com/silexphp/Silex/blob/1.2/README.rst#tests is currently lying, and there are two options

• require users to install phpunit globally, remove the instructions on how to install dev depencencies, and change the line for running the tests to $ phpunit or
• require phpunit/phpunit as a dev depenceny

Most information in the https://github.com/fabpot/Silex/commit/7c73f2e9c1afea86c0e0d58b20bf21a0a5590ac3 commit message.

Still to be done before eventually merging it:

• Add/Update unit tests
• Update the documentation accordingly (DONE)
• Describe the change in CHANGELOG

I'm quite satisfied with the new design (but the code is still very new and I've not used it extensively yet). One thing that I want to discuss is names. For instance, ControllerCollection should probably be renamed to ApplicationBuilder or something similar to better reflect what it does. Also, I'm not really happy with the connect() name in ApplicationExtensionInterface.

Can some of you try to convert existing code to the new way and tell me if it works better than the current way?

The problem description is available from: http://stackoverflow.com/questions/24933045/silex-framework-user-is-always-anonymous

System: Ubuntu 14.04 Architecture: amd64 HHVM Version: 3.2.0~trusty Silex Version: ~1.1

Not tested with 1.2.

edited again Fabpot did a PR here: https://github.com/fabpot/Silex/pull/110

Adding support for multiple databases.

This is my first attempt to try and eliminate the multiple Doctrine Extensions. This does NOT provide any ORM support (I intend to make a different extension for that in the future), however it does make my extension https://github.com/awildeep/Silex-DoctrineMultiDbExtension obsolete.

I was attempting to make this backwards compatible, however the suggestions to change the name of the Extension DoctrineDbalExtension, as well as the service name dbal has made this impossible. However the goal of keeping this similar to the old extension remains to make transitioning easier.

I am not sure the documentation is adequate, so please feel free to leave some feedback.

A link to the ticket: https://github.com/fabpot/Silex/issues/102

Submitted suggestions:

1. Formatting corrections and whitespace (tabs, spaces, and some other issues). [Complete]
2. Service name changed from db to dbal. [Complete]
3. Prefixing connections in the service with dbal.connection.<connection_name>. [Complete]
4. Creating a default connection (by default the first defined connection, but also user configurable) accessed via dbal. [Complete]
5. Renaming the extension to DoctrineDbalExtension, as this more aptly describes its function. A future DoctrineOrmExtension is planned, but will not be started until this extension is resolved. [Complete]

Concerns:

1. Breaking backwards compatibility. We are waiting to hear from @fabpot on how to handle this. Note if we can not, it is an extremely easy change to roll back to a point where BC does not break.
2. Documentation clarity. I am wondering if the current doc is adequate, and a link to a sub-page for dealing with multiple database connections would be more logical. Doing it this way we could even show more examples with more specific cases.

Edited:

• I removed the portion of this text about not breaking compatibility due to the class name change and the service name change. Also I am trying to keep a list of the changes that have been made since this thread is getting very long.
• Added a section for concerns to keep them tidy/handy.
• Added more formatting, and compiled more information into this post to make this wall of text easier to read.

Hi !

As discussed in #262 and in my previous similar PR (https://github.com/fabpot/Silex/pull/270) with @GromNaN, here is another implementation of the Routes Middlewares feature, shipped with its Unit Test.

The feature addition is still 100% backward compatible, but this time it may be more "Silex style" compliant - and it's "100% no performance loss" :-)

With this PR the Silex Controller class has a new before() method, which registers a callback to trigger when the Route is matched, just before the route callback itself. This before() method can be called more than one time on a single Route definition, allowing multiple secondary callbacks (a.k.a. "Routes Middlewares") to be executed before the Route main callback.

Would this feature be eligible for Silex integration, like this ?

Olivier

Hi,

this is so sad to see that development for Silex is being stopped. To me Silex was the best MicroFramework for PHP. I have dozens of projects depending on it. I think the current maintainers had done a great job.

The problem ist, not all my customers will be willing to pay for migrating to Symfony. Also in the past years i've made this experience way too much, that you write an application and then all off a sudden the Framework is being abandoned or the next version is incompatible with your old code. For example Zend Framework 1. For this reason, i will never use a full fledged framework again. MicroFrameworks are at least so small, that you can support it your self if you must.

I don't want to see Silex to dissappear. It was way to good. I would like to ask if there would be anybody willing to help me with a fork and help Silex to stay alive, even if it has to be renamed. The main goal would be to establish a stable release, that will be supported for at least 3 years. The second goal would be to catch up with Symfony and be able to use Symfony 4 components.

Best,

Gunnar

I'd like to be able to be able to use variables in mount paths:

$app->mount('/{year}/{month}/', function ($year, $month) {
    return new YearMonthController($year, $month);
})
->assert('year', '\d\d\d\d')
->convert('year', function ($year) { return (int)$year; })
->assert('month', '\d\d|\d')
->convert('month', function ($month) { return (int)ltrim($month, '0'); })
;

For a specific year and month, say 2015 and 07 respectively, this should work the same way as

$app->mount('/2015/07/', new YearMonthController(2015, 7));

See also http://stackoverflow.com/questions/18987808/silex-variable-mount-point for someone having the same kind of wish.

Based on #51 and #132, here is another implementation of the same idea:

• the debug parameter is guessed based on the $_SERVER array (which avoids depending on a Request being available). It can easily be overridden if needed but the default should be good enough in most cases.
• the exception handler is registered by default (still based on the default exception handler provided by the HttpKernel component) but it can easily be disabled if needed: unset($app['exception_handler']).

That should make everybody happy.

Here is my app https://gist.github.com/1817117

Ofc I have Twig in vendor/twig/lib.

And when you look at https://github.com/fabpot/Silex/blob/master/src/Silex/Provider/TwigServiceProvider.php#L40 it uses \Twig_Environment and register prefix at https://github.com/fabpot/Silex/blob/master/src/Silex/Provider/TwigServiceProvider.php#L90 which is too late, in't it?