[HttpKernel] [WebProfilerBundle] Better handling of deprecated methods
merged branch colinfrei/deprecatedErrorHandling (PR #6173)

This PR was squashed before being merged into the master branch (closes #6173).

Commits
-------

4878ec0 [HttpKernel] [WebProfilerBundle] Better handling of deprecated methods

Discussion
----------

[HttpKernel] [WebProfilerBundle] Better handling of deprecated methods

Bug fix: no
Feature addition: yes
Backwards compatibility break: yes, if you were expecting E_USER_DEPRECATED or E_DEPRECATED to throw an exception
Symfony2 tests pass: yes
Fixes the following tickets: #6139 partly, I'd go through and add the actual trigger_error() calls in another (or possibly one per component) PR
Todo: call trigger_error()
License of the code: MIT
Documentation PR: -

I added the deprecation count with the Exception icon in the Profiler Toolbar, and changed the color of it to be yellow for deprecations and red for exceptions (was yellow for exceptions).

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

by fabpot at 2012-12-03T09:43:09Z

Adding trigger_error calls should be done in one PR to ease the merging. thanks.
[FrameworkBundle] Added caching to TemplateController
merged branch KingCrunch/feature/static-template-cache (PR #6083)

This PR was squashed before being merged into the master branch (closes #6083).

Commits
-------

6236c18 [FrameworkBundle] Added caching to TemplateController

Discussion
----------

[FrameworkBundle] Added caching to TemplateController

Because the main purpose for the `TemplateController` seems to be to render static pages like "disclaimer" and such, it seems useful to allow caching.

    imprint:
        pattern: /imprint
        defaults:
            _controller: SymfonyFrameworkBundle:Template:template
            template: "::pages/imprint.html.twig"
            maxAge: 86400

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

by pierredup at 2012-11-21T20:24:53Z

IMHO I think the caching should be allowed to be set optionally

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

by KingCrunch at 2012-11-21T20:38:54Z

I wrote it this way, because I assume, that it will cover more use-cases, than the other way round, but you are right, that this will change the current behaviour. Would like to hear other opinions, because I don't think one uses this action for anything else than fully-static content (means: The current behaviour doesn't feel very useful to me).

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

by pierredup at 2012-11-21T20:48:19Z

I totally agree, but I would then suggest keep the caching on by default, but have the option to turn it off if necessary

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

by pierredup at 2012-11-21T20:52:01Z

Actually I think to have caching permanently enabled for static content would probably be the best scenario, but I like to think in terms of flexibility and specific user requirements. It would be great to get some opinions from others on this

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

by KingCrunch at 2012-11-23T21:12:45Z

I thought about it and I come to the conclusion, that it is probably a not so good idea to enable caching by default, because ... well, it's not possible to disable it again. I guess something like this

    {{ render '@AcmeBundle:ArticleController:latest' with {count: 1} }}

may be not so uncommon as I suggested in the first commit.

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

by fabpot at 2012-12-03T22:18:51Z

Can you make a PR for the docs? (symfony/symfony-docs). Thanks.
fixed CS