Commits
-------

eaf176d3 added a Route class
e3ddad54 added the possibility for settings set on a controller collection to influence controllers register later on
0356873a changed Controller::generateRouteName() visibility
31652440 added a way to define settings for all routes of a collection (closes #186)

Discussion
----------

added a way to define settings for all routes of a collection (closes #186)

see the ticket and docs from the patch.

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

by fabpot at 2012-05-21T13:00:13Z

ok, I've changed the strategy to what I've described above. ping @igorw

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

by igorw at 2012-05-21T16:09:56Z

`ControllerCollection extends Controller` is weird. I see how some code can be re-used, but a controller cannot be frozen or named, so those parts don't really make sense to me.

Apart from that it's a nice feature. If you can come up with a cleaner way to do it that doesn't bloat the code too much, that'd be nice.

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

by fabpot at 2012-05-21T16:30:16Z

What about creating a `Route` class that extends the Symfony `Route` class? It would contain the `assert`, `value`, `requireHttp`, `requireHttps`, `convert`, and `middleware` methods. Then, `Controller` and `ControllerCollection` extend this new `Route` class.

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

by fabpot at 2012-05-21T16:33:23Z

Extending the `Route` is not necessarily a good idea either. What about creating this `Route` class and compose it into both `Controller` and `ControllerCollection`?

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

by fabpot at 2012-05-21T16:33:50Z

That's what my last commit does.

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

by fabpot at 2012-05-21T16:36:34Z

By the way, a Trait would probably have been the best solution.

added the possibility for settings set on a controller collection to influence controllers register later on

Commits
-------

d2a9a6f6 [Doc/Testing] Replaced assertEquals(1, count(...)) with assertCount(1, ...)

Discussion
----------

[Doc] Used assertCount(1, ...) instead of assertEquals(1, count(..)) in Testing

It's better to use the `assertCount()` method from PHPunit for testing a length of a array. This method is avaible since PHPunit 3.6.0

Commits
-------

1f952470 made mention of the FallbackResource, which makes rewriting even easier

Discussion
----------

made mention of the FallbackResource, which makes rewriting even easier

As the Apache FallbackResource directive makes rewriting even easier (and also faster) than mod_rewrite, I thought I'd mention it in the docs.

Commits
-------

f1414641 Tweaked composer.json

Discussion
----------

Tweaked composer.json

* Symfony components  now require php >= 5.3.3
* Pimple is now taggured

* Symfony components  now require php >= 5.3.3
* Pimple is now taggured

Commits
-------

afbd26e0 [Travis] Removed tests on php 5.3.2

Discussion
----------

[Travis] Removed tests on php 5.3.2

Like in symfony/symfony

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

by igorw at 2012-05-12T15:10:16Z

If you look at the commit on symfony/symfony, it removes the tests for 5.3.3, because that version is not available on travis.

Depending on why exactly it was bumped on symfony/symfony, it may make sense to bump the official requirement of silex/silex to 5.3.3 as well.

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

by lyrixx at 2012-05-12T15:13:56Z

They removed support of php 5.3.2 because of ubuntu 10.04 LTS is deprecated. Now ubuntu 12.04 (new LTS) supports php 5.3.3

As symfony 2 drop support of php 5.3.2, I think silex have to drop this support ?
My be I forgot to update composer.json ?

Commits
-------

16872871 Call terminate() after sending the response in HttpCache

Discussion
----------

Call terminate() after sending the response in HttpCache