[FrameworkBundle] recursively resolve container parameter placeholders
for arrays in router _defaults
[TwigBundle] added support for Twig namespaced paths (Twig 1.10)

In a template, you can now use native Twig template names, instead of
the Symfony ones:

Before (still works):

    {% extends "AcmeDemoBundle::layout.html.twig" %}
    {% include "AcmeDemoBundle:Foo:bar.html.twig" %}

After:

    {% extends "@AcmeDemo/layout.html.twig" %}
    {% include "@AcmeDemo/Foo/bar.html.twig" %}

Using native template names is also faster.

The only drawback is that the new notation looks similar to the way we
locate resources in Symfony, which would be
@AcmeDemoBundle/Resources/views/Foo/bar.html.twig. We could have used
the same notation, but it is rather verbose (and by the way, using this
notation did not work anyway in templates).
Map normalized header names to original capitalization
merged branch gigablah/header_caps (PR #5662)

This PR was merged into the master branch.

Commits
-------

63a228c Map normalized header names to original capitalization

Discussion
----------

[HttpFoundation] Preserve capitalization of response header names

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/gigablah/symfony.png)](http://travis-ci.org/gigablah/symfony)
License of the code: MIT
Fixes the following tickets: -
Todo: -

`HeaderBag` normalizes header names when they are set. Therefore, custom header names (e.g. X-Sendfile, Vary) are output in lowercase. I've added an array to map header keys to their original capitalization in `ResponseHeaderBag`. Calling `allPreserveCase()` will now output the header array with capitalization preserved.

More of a cosmetic (and consistency) fix, since HTTP header names are case insensitive.

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

by pborreli at 2012-10-03T16:09:31Z

may not work with
```
ETag
Content-MD5
P3P
WWW-Authenticate
X-UA-Compatible
X-XSS-Protection
```

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

by fabpot at 2012-10-03T17:14:12Z

This overrhead is not needed most of the time. It should be done in a response listener if you have the issue. But as far as the RFC is concerned, this is not needed.

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

by gigablah at 2012-10-04T13:51:59Z

I've reworked my approach to account for the cases mentioned by @pborreli. `ResponseHeaderBag` now contains an array to map the header keys to their original capitalized names. This is much cleaner compared to string manipulation. I've also added a simple test case.

Please let me know if there's merit to this, failing which I'll just extend the class in my projects.

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

by fabpot at 2012-10-04T14:10:28Z

@gigablah This approach looks much better indeed.

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

by gigablah at 2012-10-04T15:29:29Z

Thanks! I've squashed the commits and added more test data.

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

by pborreli at 2012-10-04T15:49:05Z

Thank you, it's a nice PR :+1:
merged branch fabpot/twig (PR #5660)

This PR was merged into the master branch.

Commits
-------

5c809d8 [TwigBundle] added support for Twig namespaced paths (Twig 1.10)

Discussion
----------

[TwigBundle] added support for Twig namespaced paths (Twig 1.10)

In a template, you can now use native Twig template names, instead of
the Symfony ones:

Before (still works):

    {% extends "AcmeDemoBundle::layout.html.twig" %}
    {% include "AcmeDemoBundle:Foo:bar.html.twig" %}

After:

    {% extends "@AcmeDemo/layout.html.twig" %}
    {% include "@AcmeDemo/Foo/bar.html.twig" %}

Using native template names is also faster.

The only drawback is that the new notation looks similar to the way we
locate resources in Symfony, which would be
`@AcmeDemoBundle/Resources/views/Foo/bar.html.twig`. We could have used
the same notation, but it is rather verbose (and by the way, using this
notation did not work anyway in templates).

TODO: update documentation

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

by fabpot at 2012-10-03T13:36:56Z

I forgot to mention why I'd like to include this change besides performance: this would allow to share templates between a project using the Symfony2 full-stack framework and any other project using Twig.

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

by henrikbjorn at 2012-10-03T13:50:48Z

:+1: Will the old notation be deprecated at some point?

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

by stof at 2012-10-03T14:29:50Z

@fabpot does it still support overwriting templates ?
merged branch docteurklein/fix-router-resolve-string (PR #4995)

This PR was merged into the master branch.

Commits
-------

4b86765 [FrameworkBundle] recursively resolve container parameter placeholders for arrays in router _defaults

Discussion
----------

[2.2] [FrameworkBundle] avoid trying to resolve container placeholders on arrays on router _defaults

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~

Permits to pass arrays in route `_defaults`.

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

by stof at 2012-07-20T13:07:36Z

This seems weird. An array could contain parameters in it.

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

by docteurklein at 2012-07-20T13:17:00Z

@stof An object too then, no ? Why accepting objects but not arrays ? Would you propose to recursively resolve array values ?

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

by stof at 2012-07-20T13:31:06Z

@docteurklein Resolving array values recursively would be consistent with the way the DIC parameters are resolved. I don't really see how you would resolve objects (and btw, it is pretty much an edge case as you cannot really put an object in your routes if you define them in your YAML or XML config files or with annotations)

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

by docteurklein at 2012-07-20T13:36:43Z

@stof I agree. I can manage recursive array resolving if needed.

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

by fabpot at 2012-07-23T13:58:07Z

Can you squash your commits before I merge? Thanks.

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

by docteurklein at 2012-07-23T14:39:17Z

@fabpot  done.