* 2.3:
moved some fixed dep versions from 2.2.* to ~2.2 (refs #8613)
[HttpKernel] added a missing dep for dev
[Form] fixed wrong call to setTimeZone() (closes#8644)
Fix issue with \DateTimeZone::UTC / 'UTC' for PHP 5.4
[Form] Fixed patched forms to be valid even if children are not submitted
Revert "[Form] Fix of "PATCH'ed forms are never valid""
[Form] Fixed: If a form is not present in a request, it is not automatically submitted
Fixes link indices
[Form] Removed the "disabled" attribute from the placeholder option in select fields due to problems with the BlackBerry 10 browser
Revert "[Form] Remove "value" attribute on empty_value option"
[routing] added ability for apache matcher to handle array values
removed dead code and fixed CS
[Validator] fixed StaticMethodLoader trying to invoke methods of abstract classes (closes#8589)
* 2.2:
[HttpKernel] added a missing dep for dev
[Form] fixed wrong call to setTimeZone() (closes#8644)
Fix issue with \DateTimeZone::UTC / 'UTC' for PHP 5.4
[Form] Removed the "disabled" attribute from the placeholder option in select fields due to problems with the BlackBerry 10 browser
[routing] added ability for apache matcher to handle array values
removed dead code and fixed CS
[Validator] fixed StaticMethodLoader trying to invoke methods of abstract classes (closes#8589)
Conflicts:
src/Symfony/Bundle/TwigBundle/TokenParser/RenderTokenParser.php
src/Symfony/Component/Form/FormConfigBuilder.php
src/Symfony/Component/HttpKernel/composer.json
src/Symfony/Component/Validator/Tests/GraphWalkerTest.php
This PR was merged into the master branch.
Discussion
----------
[FrameworkBundle] fixed regression where the command might have the wrong container if the application is reused several times
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
This fixes a regression introduced in #8242. Before this PR, the commands were always getting the current container registered in the kernel. But as the commands are now registered only once, if the container changes, the commands were not aware of this change. That happens quite frequently in functional tests where the Kernel is booted and shutdown several times in the same process.
Commits
-------
1bd45b3 [FrameworkBundle] fixed regression where the command might have the wrong container if the application is reused several times
* 2.3:
[Form] fixes empty file-inputs get treated as extra field
return 0 if there is no valid data
[DependencyInjection] fixed regression where setting a service to null did not trigger a re-creation of the service when getting it
[DependencyInjection] fixed#8570
fixed file permission
The ignoreAttributes itself should be ignored, too.
[Tests] Tests on php 5.5 should pass
[Twig] fixed TwigEngine::exists() method when a template contains a syntax error (closes#88546)
* 2.3:
Update JsonResponse.php
[HttpKernel] fixed the inline renderer when passing objects as attributes (closes#7124)
CookieJar remove unneeded var, Client remove unneeded else
[DI] Fixed bug requesting non existing service from dumped frozen container
Update validators.sk.xlf
[WebProfiler] fix content-type parameter
Replace romaji period characters with Japanese style zenkaku period characters
fixed CS
fixed CS
[Console] Avoided an unnecessary check.
Added missing French validator translations
typo first->second
Passed the config when building the Configuration in ConfigurableExtension
removed unused code
Fixed variable name used in translation cache
Conflicts:
src/Symfony/Component/Console/Event/ConsoleCommandEvent.php
* 2.2:
Update JsonResponse.php
[HttpKernel] fixed the inline renderer when passing objects as attributes (closes#7124)
[WebProfiler] fix content-type parameter
Replace romaji period characters with Japanese style zenkaku period characters
Passed the config when building the Configuration in ConfigurableExtension
Conflicts:
src/Symfony/Bundle/FrameworkBundle/Tests/Functional/Bundle/TestBundle/Resources/config/routing.yml
src/Symfony/Component/HttpKernel/Tests/Fragment/InlineFragmentRendererTest.php
This PR was merged into the master branch.
Discussion
----------
[Templating|FrameworkBundle] Made DelegatingEngine::getEngine() public
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #7254
| License | MIT
| Doc PR | -
As a bonus I've covered both classes with tests.
Commits
-------
a54cbff [FrameworkBundle] Made DelegatingEngine::getEngine() public.
3f84cd3 [Templating] Made DelegatingEngine::getEngine() public.
0a72a99 [FrameworkBundle] Added tests for the DelegatingEngine.
6c31ab2 [Templating] Added tests for the DelegatingEngine.
When a null is provided for framework.session.handler_id the FrameworkExtension attempts to set the session storage to null for the 'session.storage.php_bridge' by altering the second argument. According to the session.xml service definition, there is no second argument, and it is in fact the first (read, 0 index) argument that should be changed.
Before:
enabled: true # the profiler is enabled and data are collected
enabled: false # the profiler is enabled but data are not collected (data can be collected on demand)
No way to disable the profiler
After:
enabled: true # the profiler is enabled and data are collected
collect: true
enabled: true # the profiler is enabled but data are not collected (data can be collected on demand)
collect: false
enabled: false # the profiler is disabled
This PR was merged into the master branch.
Discussion
----------
make it possible to ignore route attributes in the RedirectContoller
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
```
_welcome:
pattern: /{path}
defaults:
_controller: FrameworkBundle:Redirect:redirect
route: licenses_projects
ignoreAttributes: true
requirements:
path: .*
```
or
```
_welcome:
pattern: /{path}
defaults:
_controller: FrameworkBundle:Redirect:redirect
route: licenses_projects
ignoreAttributes: [path]
requirements:
path: .*
```
Ensures that ``path`` isnt added as a GET parameter in case the ``licenses_projects`` doesnt have a path in the pattern.
Commits
-------
190abc1 add unit tests for $ignoreAttributes
0c7b65f inject the Request via the action signature, rather than fetching it from the DIC
49062aa make it possible to ignore route attributes in the RedirectContoller
This PR was merged into the master branch.
Discussion
----------
[2.3][Session] Give greater control over how and when session starts
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | na
| License | MIT
| Doc PR | symfony/symfony-docs#2475
Refs #6036
Gives control over how start on demand works: allowing to turn it on or off and to allow bag access when session is off.
Commits
-------
f431cb0 Fix tests
1f521d8 Coding standards
2583c26 [HttpFoundation][FrameworkBundle] Keep save auto_start behaviour as in 2.2 and make component values consistent with FrameworkBundle's configuration options.
ceaf69b [FrameworkBundle] Use more sophisticated validation and configuration.
af0a140 [FrameworkBundle] Add configuration to allow control over session start on demand.
8fc2397 [HttpFoundation] Give control over how session start on demand.
This PR was merged into the master branch.
Discussion
----------
[2.3] [WIP] Synchronized services...
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #5300, #6756
| License | MIT
| Doc PR | symfony/symfony-docs#2343
Todo:
- [x] update documentation
- [x] find a better name than contagious (synchronized)?
refs #6932, refs #5012
This PR is a proof of concept that tries to find a solution for some problems we have with scopes and services depending on scoped services (mostly the request service in Symfony).
Basically, whenever you want to inject the Request into a service, you have two possibilities:
* put your own service into the request scope (a new service will be created whenever a sub-request is run, and the service is not available outside the request scope);
* set the request service reference as non-strict (your service is always available but the request you have depends on when the service is created the first time).
This PR addresses this issue by allowing to use the second option but you service still always has the right Request service (see below for a longer explanation on how it works).
There is another issue that this PR fixes: edge cases and weird behaviors. There are several bug reports about some weird behaviors, and most of the time, this is related to the sub-requests. That's because the Request is injected into several Symfony objects without being updated correctly when leaving the request scope. Let me explain that: when a listener for instance needs the Request object, it can listen to the `kernel.request` event and store the request somewhere. So, whenever you enter a sub-request, the listener will get the new one. But when the sub-request ends, the listener has no way to know that it needs to reset the request to the master one. In practice, that's not really an issue, but let me show you an example of this issue in practice:
* You have a controller that is called with the English locale;
* The controller (probably via a template) renders a sub-request that uses the French locale;
* After the rendering, and from the controller, you try to generate a URL. Which locale the router will use? Yes, the French locale, which is wrong.
To fix these issues, this PR introduces a new notion in the DIC: synchronized services. When a service is marked as synchronized, all method calls involving this service will be called each time this service is set. When in a scope, methods are also called to restore the previous version of the service when the scope leaves.
If you have a look at the router or the locale listener, you will see that there is now a `setRequest` method that will called whenever the request service changes (because the `Container::set()` method is called or because the service is changed by a scope change).
Commits
-------
17269e1 [DependencyInjection] fixed management of scoped services with an invalid behavior set to null
bb83b3e [HttpKernel] added a safeguard for when a fragment is rendered outside the context of a master request
5d7b835 [FrameworkBundle] added some functional tests
ff9d688 fixed Request management for FragmentHandler
1b98ad3 fixed Request management for LocaleListener
a7b2b7e fixed Request management for RequestListener
0892135 [HttpKernel] ensured that the Request is null when outside of the Request scope
2ffcfb9 [FrameworkBundle] made the Request service synchronized
ec1e7ca [DependencyInjection] added a way to automatically update scoped services
This PR was squashed before being merged into the master branch (closes#7202).
Commits
-------
817453c [2.2] add http_method_override option to ease setup
Discussion
----------
[2.2] add http_method_override option to ease setup
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
This PR was merged into the master branch.
Commits
-------
0ef08f5 [Translator] fixed inconsistency in Translator
Discussion
----------
[2.3] [Translator] fixed inconsistency in Translator
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by stof at 2013-02-17T20:44:32Z
shouldn't you make ``setFallbackLocale`` call ``setFallbackLocales`` ?
---------------------------------------------------------------------------
by fabpot at 2013-02-18T14:04:39Z
@stof: done
---------------------------------------------------------------------------
by stof at 2013-02-18T14:18:10Z
shoudn't you also update the place where the method is used (in FrameworkBundle probably) to use the non-deprecated one ?
This PR was merged into the 2.2 branch.
Commits
-------
73aa7d1 replaced usage of the deprecated pattern routing key (replaced with path)
Discussion
----------
replaced usage of the deprecated pattern routing key (replaced with path)
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
---------------------------------------------------------------------------
by lsmith77 at 2013-02-07T13:35:54Z
do we have tests to cover the BC behavior?
---------------------------------------------------------------------------
by fabpot at 2013-02-07T16:30:31Z
I've just added some tests for the legacy way.
HttpContentRenderer has been renamed to FragmentHandler.
The RendererStrategy subnamespace has been renamed to Fragment.
The strategy classes now have Fragment in their names.
ProxyRouterListener has been renamed to FragmentListener
The router_proxy configuration entry has been renamed to fragments.
As explained in #6775, this has been done for the following reasons:
1. It's also Request::getHost()
2. The term hostname has been obsoleted in
http://tools.ietf.org/html/rfc3986#appendix-D.2 and uses the host only
3. hostname in the RFC was defined as the registered domain name, but we
probably also want to match IP-Adresses with the pattern which is the
host = IP-literal / IPv4address / reg-name for.
This PR was merged into the master branch.
Commits
-------
9fc7def added the UPGRADE file for Symfony 3.0
e84cad2 [Routing] updated CHANGELOG
65eca8a [Routing] added new schemes and methods options to the annotation loader
5082994 [Routing] renamed pattern to path
b357caf [Routing] renamed hostname pattern to just hostname
e803f46 made schemes and methods available in XmlFileLoader
d374e70 made schemes and methods available in YamlFileLoader
2834e7e added scheme and method setter in RouteCollection
10183de make scheme and method requirements first-class citizen in Route
Discussion
----------
Routing options
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | yes
| Tests pass? | yes
| Fixed tickets | #5989, #5990, #6049
| License | MIT
In #5989, it has unanimously been decided to renamed `hostname_pattern` to `hostname` and `pattern` to `path`. That makes a lot of sense and I would like to do the renaming now as `hostname_pattern` is new in Symfony 2.2, so I'd like to avoid breaking BC just after the release. As we are modifying the route options, I've also included changes introduced by @Tobion in #6049 which were discussed in #5990.
As everything is BC, I think it's wise to include that in 2.2. What do you think?
---------------------------------------------------------------------------
by Tobion at 2013-01-14T18:25:53Z
I agree it should be done in 2.2. Thanks for working on it.
---------------------------------------------------------------------------
by vicb at 2013-01-14T23:11:12Z
@fabpot "Everything is BC" until it breaks BC in 3.0, that's why I'd like to see [deprecations in PR summary](https://github.com/symfony/symfony-docs/pull/2116) what do you think ?
---------------------------------------------------------------------------
by vicb at 2013-01-14T23:16:40Z
it would also be great to update the CHANGELOG with deprecations (it could also help people answering your question)
---------------------------------------------------------------------------
by fabpot at 2013-01-15T07:07:03Z
@vicb: I've just updated the CHANGELOG and created the UPGRADE file for 3.0.
---------------------------------------------------------------------------
by vicb at 2013-01-15T07:15:32Z
@fabpot thanks.
This PR was merged into the master branch.
Commits
-------
76fefe3 updated CHANGELOG and UPGRADE files
f7da1f0 added some unit tests (and fixed some bugs)
f17f586 moved the container aware HTTP kernel to the HttpKernel component
2eea768 moved the deprecation logic calls outside the new HttpContentRenderer class
bd102c5 made the content renderer work even when ESI is disabled or when no templating engine is available (the latter being mostly useful when testing)
a8ea4e4 [FrameworkBundle] deprecated HttpKernel::forward() (it is only used once now and not part of any interface anyway)
1240690 [HttpKernel] made the strategy a regular parameter in HttpContentRenderer::render()
adc067e [FrameworkBundle] made some services private
1f1392d [HttpKernel] simplified and enhanced code managing the hinclude strategy
403bb06 [HttpKernel] added missing phpdoc and tweaked existing ones
892f00f [HttpKernel] added a URL signer mechanism for hincludes
a0c49c3 [TwigBridge] added a render_* function to ease usage of custom rendering strategies
9aaceb1 moved the logic from HttpKernel in FrameworkBundle to the HttpKernel component
Discussion
----------
[WIP] Kernel refactor
Currently, the handling of sub-requests (including ESI and hinclude) is mostly done in FrameworkBundle. It makes these important features harder to implement for people using only HttpKernel (like Drupal and Silex for instance).
This PR moves the code to HttpKernel instead. The code has also been refactored to allow easier integration of other rendering strategies (refs #6108).
The internal route has been re-introduced but it can only be used for trusted IPs (so for the internal rendering which is managed by Symfony itself, or by a trusted reverse proxy like Varnish for ESI handling). For the hinclude strategy, when using a controller, the URL is automatically signed (see #6463).
The usage of a listener instead of a controller to handle internal sub-requests speeds up things quite a lot as it saves one sub-request handling. In Symfony 2.0 and 2.1, the handling of a sub-request actually creates two sub-requests.
Rendering a sub-request from a controller can be done with the following code:
```jinja
{# default strategy #}
{{ render(path("partial")) }}
{{ render(controller("SomeBundle:Controller:partial")) }}
{# ESI strategy #}
{{ render(path("partial"), { strategy: 'esi' }) }}
{{ render(controller("SomeBundle:Controller:partial"), { strategy: 'esi' }) }}
{# hinclude strategy #}
{{ render(path("default1"), { strategy: 'hinclude' }) }}
```
The second commit allows to simplify the calls a little bit thanks to some nice syntactic sugar:
```jinja
{# default strategy #}
{{ render(path("partial")) }}
{{ render(controller("SomeBundle:Controller:partial")) }}
{# ESI strategy #}
{{ render_esi(path("partial")) }}
{{ render_esi(controller("SomeBundle:Controller:partial")) }}
{# hinclude strategy #}
{{ render_hinclude(path("default1")) }}
```
---------------------------------------------------------------------------
by fabpot at 2013-01-03T17:58:49Z
I've just pushed a new version of the code that actually works in my browser (but I've not yet written any unit tests). I've updated the PR description accordingly.
All comments welcome!
---------------------------------------------------------------------------
by Koc at 2013-01-03T20:11:43Z
what about `render(controller="SomeBundle:Controller:partial", strategy="esi")`?
---------------------------------------------------------------------------
by stof at 2013-01-04T09:01:01Z
shouldn't we have interfaces for the UriSigner and the HttpContentRenderer ?
---------------------------------------------------------------------------
by lsmith77 at 2013-01-04T19:28:09Z
btw .. as mentioned in #6213 i think it would make sense to refactor the HttpCache to use a cache layer to allow more flexibility in where to cache the data (including clustering) and better invalidation. as such if you are refactoring HttpKernel .. it might also make sense to explore splitting off HttpCache.
---------------------------------------------------------------------------
by fabpot at 2013-01-04T19:30:07Z
@lsmith77 This is a totally different topic. This PR is just about moving things from FrameworkBundle to HttpKernel to make them more reusable outside of the full-stack framework.
---------------------------------------------------------------------------
by fabpot at 2013-01-05T09:39:52Z
I think this PR is almost ready now. I still need to update the docs and add some unit tests. Any other comments on the whole approach? The class names? The `controller` function thingy? The URI signer mechanism? The proxy protection for the internal controller? The proxy to handle internal routes?
---------------------------------------------------------------------------
by sstok at 2013-01-05T10:08:25Z
Looks good to me 👍
---------------------------------------------------------------------------
by sdboyer at 2013-01-07T18:17:08Z
@Crell asked me to weigh in, since i'm one of the Drupal folks who's likely to work most with this.
i think i've grokked about 60% of the big picture here, and i'm generally happy with what i see. the assumption that the HInclude strategy makes about working with templates probably isn't one that we'll be able to use (and so, would need to write our own), but that's not a big deal since the whole goal here is to make strategies pluggable.
so, yeah. +1.
---------------------------------------------------------------------------
by winzou at 2013-01-09T20:21:44Z
Just for my information: will this PR be merged for 2.2 version? Thanks.
---------------------------------------------------------------------------
by stof at 2013-01-09T20:41:04Z
@winzou according to the blog post announcing the beta 1 release, yes. It is explicitly listed as being one of the reason to make it a beta instead of the first RC.
---------------------------------------------------------------------------
by winzou at 2013-01-09T20:49:36Z
OK thanks, I've totally skipped this blog post.
---------------------------------------------------------------------------
by fabpot at 2013-01-10T15:26:15Z
I've just added a bunch of unit tests and fix some bugs I found while writing the tests.
* 2.1:
fixed typo
[FrameworkBundle] fixed ESI calls
[FrameworkBundle] fixed ESI calls
bumped Symfony version to 2.1.6-DEV
updated VERSION for 2.1.5
updated CHANGELOG for 2.1.5
bumped Symfony version to 2.0.21-DEV
[FrameworkBundle] fixed trusted_proxies configuration for some edge cases
[FrameworkBundle] fixed XSD for the trusted-proxies setting
updated VERSION for 2.0.20
update CONTRIBUTORS for 2.0.20
updated CHANGELOG for 2.0.20
Conflicts:
src/Symfony/Bundle/FrameworkBundle/HttpKernel.php
src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/ConfigurationTest.php
src/Symfony/Component/HttpKernel/Kernel.php
* 2.0:
bumped Symfony version to 2.0.21-DEV
[FrameworkBundle] fixed trusted_proxies configuration for some edge cases
[FrameworkBundle] fixed XSD for the trusted-proxies setting
updated VERSION for 2.0.20
update CONTRIBUTORS for 2.0.20
updated CHANGELOG for 2.0.20
Conflicts:
CONTRIBUTORS.md
src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/ConfigurationTest.php
src/Symfony/Bundle/FrameworkBundle/Tests/DependencyInjection/Fixtures/xml/full.xml
src/Symfony/Component/HttpKernel/Kernel.php
* 2.1:
[FrameworkBundle] added support for URIs as an argument to HttpKernel::render()
[FrameworkBundle] restricted the type of controllers that can be executed by InternalController
[Process] Allow non-blocking start with PhpProcess
Making it easier to grab the PR template.
[Locale] fixed a test
Fixed failing test
fix double-decoding in the routing system
Conflicts:
src/Symfony/Component/Process/PhpProcess.php
* 2.0:
[FrameworkBundle] added support for URIs as an argument to HttpKernel::render()
[FrameworkBundle] restricted the type of controllers that can be executed by InternalController
Making it easier to grab the PR template.
fix double-decoding in the routing system
Conflicts:
README.md
src/Symfony/Bundle/FrameworkBundle/EventListener/RouterListener.php
src/Symfony/Component/Security/Http/HttpUtils.php
* 2.1:
[FrameworkBundle] fixed broken tests
[FrameworkBundle] Fixed logic under test environment.
[Session] Added exception to save method
[Session] Fixed a bug with the TestListener
Added comment
[FrameworkBundle] Added tests for trusted_proxies configuration.
[FrameworkBundle] Added a check on file mime type for CodeHelper::fileExcerpt()
checked for a potentially missing key
[FrameworkBundle] used the new method for trusted proxies
remove realpath call
Conflicts:
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
* 2.0:
Added comment
[FrameworkBundle] Added tests for trusted_proxies configuration.
[FrameworkBundle] Added a check on file mime type for CodeHelper::fileExcerpt()
checked for a potentially missing key
[FrameworkBundle] used the new method for trusted proxies
remove realpath call
Conflicts:
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
* 2.1: (29 commits)
[DependencyInjection] fixed composer.json
[Validator] Fix typos in validators.ru.xlf
Edited some minor grammar and style errors in russian validation file
Updated Bulgarian translation
[Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
[Form] simplified a test from previous merge
Update src/Symfony/Component/Form/Extension/Core/Type/FileType.php
fixed CS
Xliff with other node than source or target are ignored
small fix of #5984 when the container param is not set
Filesystem Component mirror symlinked directory fix
[Process][Tests] fixed chainedCommandsOutput tests
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
info about session namespace
fix upgrade info about locale
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
...
* 2.0:
[DependencyInjection] fixed composer.json
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
fixed CS
small fix of #5984 when the container param is not set
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
[Security] remove escape charters from username provided by Digest DigestAuthenticationListener
[Security] added test extra for digest authentication
fixed CS
[Security] Fixed digest authentication
[Security] Fixed digest authentication
[SecurityBundle] Convert Http method to uppercase in the config
Use Norm Data instead of Data
Conflicts:
src/Symfony/Bridge/Doctrine/Form/EventListener/MergeCollectionListener.php
src/Symfony/Bundle/FrameworkBundle/Controller/RedirectController.php
src/Symfony/Component/DependencyInjection/composer.json
this can happen when the config for the router is unset, but this method
does not need to depend on routing. reading an unset config would raise an exception.
The code has been duplicated and not moved for BC reasons.
This code has been duplicated in the Twig bundle to be able to decouple
the web profiler and the exception templates.
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.
Commits
-------
22e9036 updated CHANGELOG
bafe890 [FrameworkBundle] changed Client::enableProfiler() behavior to fail silently when the profiler is not available (it makes it easier to write functional tests)
f41872b [FrameworkBundle] added a way to enable the profiler for the very next request in functional tests (closes#4307)
67b91e5 [HttpKernel] added a way to enable a disable Profiler
Discussion
----------
[2.2] added a way to enable the profiler for the very next request in a functional test
Bug fix: yes/no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4307
Todo: -
License of the code: MIT
Documentation PR: should be done before merging
After merging this PR, we need to disable the profiler in the test environment in Symfony SE.
Commits
-------
3f8127c fixed '0' problem
7bec460 fixed phpdoc
4c5bfab [FrameworkBundle] non-permanent redirect should be status code 404 according to spec
Discussion
----------
[FrameworkBundle] non-permanent redirect to unknown location with 404
according to spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html see 410 Gone
bc break: tiny when omitting 2 parameter (I can avoid this with `func_num_args` but i think its not necessary and makes the code strange and inconsistent)
* 2.0:
Fixes incorrect class used in src/Symfony/Bundle/FrameworkBundle/Console/Application.php
[FrameworkBundle] added test for fix broken command registration
corrected phpdoc
The charset was configurable in a configuration file but it never worked:
framework:
charset: ISO-8859-1
Now, like for the cache and log dirs, you can configure the charset by
overriding the getCharset() method in the app kernel:
public function getCharset()
{
return 'ISO-8859-1';
}
CSRF fields are now only added when the view is built. For this reason we already know if
the form is the root form and avoid to create unnecessary CSRF fields for nested fields.
Commits
-------
cdba4cf [FrameworkBundle] Change XSD to allow string replacements on session args.
52f7955 [FrameworkBundle] Remove default from gc_* session configuration keys.
749593d [FrameworkBundle] Allow configuration of session garbage collection for session 'keep-alive'.
Discussion
----------
[2.1][FrameworkBundle] Allow configuration of session garbage collection
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2171
Todo: -
---------------------------------------------------------------------------
by drak at 2012-03-21T21:56:20Z
@fabpot - this PR is ready for merge. It basically allows configuration of some session ini values that are necessary in controlling the session behaviour.
---------------------------------------------------------------------------
by dlsniper at 2012-03-21T22:57:18Z
@drak shouldn't all the options here: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php#L266 be available for configuration, or am I just reading the source wrong and they already are?
In this case should I make a separate PR to cover the rest or could you do it in this one?
---------------------------------------------------------------------------
by fabpot at 2012-03-23T14:56:22Z
@drak: the discussion is the ticket is very interesting and I think it should be part of a cookbook in the documentation. Can you take care of that before I merge this PR? Thanks.
---------------------------------------------------------------------------
by drak at 2012-03-25T15:32:59Z
@fabpot - yes - it's on the todo list. Will update this PR when done.
---------------------------------------------------------------------------
by drak at 2012-03-26T19:45:13Z
@fabpot - this is ready for merging, the documentation is done (the PR is in but I'll tweak it, but no need to wait to merge this PR). I will also add something extra to cookbook (I wrote docs for the component).
Revert service back to session.storage.native
Rename session.storage.native_file to session.handler.native_file (which is the default so no BC break from 2.0)
Commits
-------
9d6eb82 [Routing] Fix a bug in the TraceableUrlMatcher
9fc8d28 [FrameworkBundle] Fix a bug in the RedirectableUrlMatcher
4fcf9ef [Routing] Small optimization in the UrlMatcher
abc2141 [Routing] Added a missing property declaration
d86e1eb [Routing] Remove a weird dependency
Discussion
----------
[Routing] Remove a dependency on a derived class, fixes, optim
Subset of #3296 which should be acceptable.
Travis is happy.
The side effect of removing the dependency is that the `UrlMatcher` does not throw an exception any more when the scheme does not match the required scheme. I think it is better because:
* it removes a dependency on a derived class,
* it was an undocumented "feature",
* other thrown excs are component specific while this one was raw SPL.
---------------------------------------------------------------------------
by vicb at 2012-02-09T14:43:02Z
let me know what should go in 2.0 as well.
Rename ArraySessionStorage to make it clear the session is a mock for testing purposes only.
Has BC class for ArraySessionStorage
Added sanity check when starting the session.
Fixed typos and incorrect php extension test method
session_module_name() also sets session.save_handler, so must use extension_loaded() to check if module exist
or not.
Respect autostart settings.
Commits
-------
753c067 [FrameworkBundle] added $view['form']->csrfToken() helper
e1aced8 [Twig] added {{ csrf_token() }} helper
Discussion
----------
[Twig] [FrameworkBundle] added CSRF token helper
I've added a templating helper and Twig function for generating a CSRF token without the overhead of creating a form.
```html+jinja
<form action="{{ path('user_delete', { 'id': user.id }) }}" method="post">
<input type="hidden" name="_method" value="delete">
<input type="hidden" name="_token" value="{{ csrf_token('delete_user_' ~ user.id) }}">
<button type="submit">delete</button>
</form>
```
```php
<?php
class UserController extends Controller
{
public function delete(User $user, Request $request)
{
$csrfProvider = $this->get('form.csrf_provider');
if (!$csrfProvider->isCsrfTokenValid('delete_user_'.$user->getId(), $request->request->get('_token')) {
throw new RuntimeException('CSRF attack detected.');
}
// etc...
}
}
```
The test that is failing on Travis appears to be unrelated, but I may be wrong?
```
1) Symfony\Bundle\SecurityBundle\Tests\Functional\LocalizedRoutesAsPathTest::testLoginLogoutProcedure with data set #1 ('de')
RuntimeException: OUTPUT:
Catchable fatal error: Argument 3 passed to Symfony\Bundle\FrameworkBundle\Controller\TraceableControllerResolver::__construct() must be an instance of Symfony\Component\HttpKernel\Debug\Stopwatch, instance of Symfony\Bundle\FrameworkBundle\Controller\ControllerNameParser given, called in /tmp/2.1.0-DEV/StandardFormLogin/cache/securitybundletest/appSecuritybundletestDebugProjectContainer.php on line 94 and defined in /home/vagrant/builds/kriswallsmith/symfony/src/Symfony/Bundle/FrameworkBundle/Controller/TraceableControllerResolver.php on line 37
```
---------------------------------------------------------------------------
by pablodip at 2012-01-10T14:18:45Z
As you don't need forms to use the csrf provider, how about putting its service without the form prefix? It could even make sense to put the CsrfProvider as a component since you can use it standalone and in more cases than only forms. It would be a small component though.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T17:54:14Z
I think it would be more clear to generate the token in the controller. Doing so in the template will spread the CSRF intention across template and controller. So I don't think this extension is necessary.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-10T17:58:14Z
@pablodip I'm open to the idea of a Csrf component. This would be a good place for some nonce classes as well.
@Tobion I disagree. One use case is for a list of users, each with a delete form. Iterating over the users in the controller and generating a token for each, just to iterate over them again in the view is a waste and adds complexity.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T18:05:14Z
I see. But I don't understand why the intention needs to be different for each user to delete. Usually the intention is the same for each form type. I thought this is enough.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-10T18:06:13Z
Yes, a static intention would suffice.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T18:07:08Z
Then your use case is not valid anymore.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T18:12:25Z
I would suggest to make a cookbook article out of it about how to create a simple form without the form component.
And include such things as validating the result using the validator component and checking the CSRF.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-10T21:32:50Z
This helper makes it easier to use CSRF protection without a form and we should make it as easy as possible. Spreading the intention across controller and template is not concerning to me. Either way, a cookbook entry is a great idea.
---------------------------------------------------------------------------
by Tobion at 2012-01-10T21:47:12Z
Well, it's just one line more without this helper. So I disagree it makes it really easier when you know how to use the CsrfProvider which is a pre-condition anyway since you must still validate its correctness by hand.
---------------------------------------------------------------------------
by kriswallsmith at 2012-01-13T13:24:15Z
Another use case is when rendering a page with a bunch of simple buttons with different intentions: delete user, delete comment, follow, unfollow... Creating all of these in the controller just leads to spaghetti.
---------------------------------------------------------------------------
by jwage at 2012-01-17T21:55:53Z
👍 lots of use cases for something like this @OpenSky
* 2.0:
fixed functional tests so that the cache/logs are specific to one version of Symfony (to avoid weird side effects)
[FrameworkBundle] Prove client insulation and non-insulation works in session tests.
[FrameworkBundle] Add tests to prove functional testing works with simultaneous clients.
[FrameworkBundle] Small changes to test setup.
[DoctrineBundle] Fixed incorrectly shown params
[SwiftmailerBundle] fixed the send email command when the queue does not extends Swift_ConfigurableSpool
* 2.0:
[FrameworkBundle] Added functional tests.
[Form] Added missing use statements (closes#2880)
[Console] Improve input definition output for Boolean defaults
[SecurityBundle] Changed environment to something unique.
2879: missing space between catch and the brace
#2688: Entities are generated in wrong folder (doctrine:generate:entities Namespace)
[TwigBundle] Fix the exception message escaping
Commits
-------
cd24fb8 change explode's limit parameter based on known variable content
b3cc270 minor optimalisations for explode
Discussion
----------
[FrameworkBundle][CssSelector][HttpFoundation][HttpKernel] [Security][Validator] Minor optimizations for "explode" function
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
I added limit parameter in some places, where it may be usefull. I did not check the context of what values may have been exploded. So to not break anything, I added +1 to limit parameter.
If you find out that in some places limit (or limit+1) is not important or meaningless, write a comment please and I will fix it.
---------------------------------------------------------------------------
by fabpot at 2011/12/07 06:56:49 -0800
Adding +1 just to be sure to not break anything is clearly something we won't do. What is the benefit of doing that anyway?
---------------------------------------------------------------------------
by pulzarraider at 2011/12/07 13:50:24 -0800
The main idea of making this PR was to notify about some places that may run faster with just adding one parameter to explode function.
If in code is someting like: ```list($a, $b) = explode(':', $s);```
Function ```explode``` will create n-items (depends on ```$s```), but we need in code only the first two items. There is no reason to let ```explode``` create more items in memory that are NEVER used in our code. The limit parameter is there for these situations, so let's use it.
I know that it is microoptimization and may look unimportant, but we are writing a framework - so people expect that code will be as fast as possible without this kind of mistakes.
As I've noticed above, I know that +1 is not ideal solution, but the fastest without debugging the code. I expect that someone (with good knowledge of that code) will look at it and write in comments if variable may contain 1 comma (dot or someting on what is doing the explode) or maybe 2 in some situations or more.
Anyway, +1 will not break anything, because same items are created as it is now, but no unnecessary item is created.
---------------------------------------------------------------------------
by fabpot at 2011/12/07 23:14:59 -0800
I'm +1 for adding the number to avoid problems but I'm -1 on the optimization side of things as it won't optimize anything.
---------------------------------------------------------------------------
by helmer at 2011/12/08 12:46:49 -0800
*.. The main idea of making this PR was to notify about some places that **may** run faster ..*
I am also unsure the optimization is really an optimization, care to benchmark (with meaningful inputs)? As for the limit+1 thing, why would you want to +1 it? The number of ``list`` arguments should always reflect the ``limit`` parameter, no?
---------------------------------------------------------------------------
by pulzarraider at 2011/12/08 23:11:34 -0800
@helmer please try this simple benchmark:
```
<?php
header('Content-Type: text/plain; charset=UTF-8');
define('COUNT', 10000);
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc:dddddddddddddddddddddd:eeeeeeeeeeeeeeeeeeeeeeeee:fffffffffffffffffffffffffff';
$start = microtime(true);
for ($i = 0; $i < COUNT; $i++) {
list($a, $b) = explode(':', $source_string);
}
$end = microtime(true)-$start;
echo 'without limit: '.$end."\n";
$start = microtime(true);
for ($i = 0; $i < COUNT; $i++) {
list($a, $b) = explode(':', $source_string, 2);
}
$end = microtime(true)-$start;
echo 'with limit: '.$end."\n";
```
My results are:
```
without limit: 0.057228803634644
with limit: 0.028676986694336
```
That is 50% difference (with APC enabled). Of course the result depends on the length of source string and if it's too short, the difference may be none or very very small. That's why I said, that it **may** run faster and is just a micro optimization.
---------------------------------------------------------------------------
by pulzarraider at 2011/12/08 23:18:12 -0800
@helmer And why +1? It depends on a code:
```
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc';
list($a, $b) = explode(':', $source_string, 2);
var_dump($a, $b);
```
and
```
$source_string = 'aaaaaaaaaaaaaaaaaaaa:bbbbbbbbbbbbbbbbbbbbb:cccccccccccccccccccccccc';
list($a, $b) = explode(':', $source_string, 3);
var_dump($a, $b);
```
gives different results. That's why the content of the variable must be known.
---------------------------------------------------------------------------
by helmer at 2011/12/09 00:08:28 -0800
@pulzarraider Thanks for the benchmark, seems like a gain enough. Although, we are more likely having a scenario of:
``explode(':', 'a🅱️c')`` vs ``explode(':', 'a🅱️c', 3)`` with a ``COUNT`` of 10, where the difference is not even in microseconds anymore :)
The limit addition alters the behaviour though, ie suddenly you can define a controller [logical name](http://symfony.com/doc/current/book/routing.html#controller-string-syntax) as ´´AcmeBlogBundle:Blog:show:something``, and things go downhill from there on.
All that aside, I'm +1 for setting the limit to the exact number of ``list`` parameters, but certainly not number+1, this is just too wtfy (as you said, this was a safety thing, but I reckon for this PR to be merged it needs to be +0).
---------------------------------------------------------------------------
by drak at 2011/12/09 08:28:58 -0800
Overall `list()` is ugly as it's not very explicit. Even though it would mean extra lines, it's better to `explode()` then explicitly assign variables:
```
$parts = explode(':', $foo);
$name = $parts[0];
$tel = $parts[1];
```
`list()` is one of those bad relics from the PHP past...
---------------------------------------------------------------------------
by fabpot at 2011/12/11 10:07:47 -0800
@drak: why is `list` not explicit? It is in fact as explicit as the more verbose syntax you propose.
---------------------------------------------------------------------------
by pulzarraider at 2011/12/11 13:08:50 -0800
@drak: I agree with @fabpot. In speech of benchmarks ```list``` is faster then using a helper variable.
@fabpot, @helmer I've changed explode's limit to be correct (without +1) and removed some changes from this PR, where I can't find out what the content of variable may be. Unit tests pass, so I think it's ready for merge.
Commits
-------
fabe818 [EventDispatcher] Add reference to the EventDispatcher on the Event
Discussion
----------
[EventDispatcher] Add reference to the EventDispatcher on the Event
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
I don't like registering event listeners unless they are really used, it seems wasteful. So I tend to register listeners for the response event in other listeners, only when they will be required. @stof has [brought to my attention](fb243ace83 (commitcomment-696467)) that this may cause issues in Silex or any other situation where event listeners are not lazy loaded, since it creates a circular reference in that case.
With this PR, avoiding the circular reference is possible, without bloating the response listener with unnecessary "do I need to do anything?" code.
---------------------------------------------------------------------------
by schmittjoh at 2011/11/06 05:28:39 -0800
Did you do any benchmarks? It's just a feeling, but registering a listener at runtime might be more expensive than just having it always executed.
Also, I find these dynamic listeners a bit of a code smell. They are not easily testable, and the control flow is harder to track. Besides, you do not take into account subrequests which might happen in between.
---------------------------------------------------------------------------
by Seldaek at 2011/11/06 09:34:27 -0800
I don't see why it would be slower, if it's a commonly fired event yes you blast away the `sorted` listener cache every time you add one, but most of the time those optional listeners are for the response, which is typically not sorted yet when you add the listener, so I don't think there is any overhead.
As for the code smell, of course it's a matter of preference, but I have the opposite view on control flow, I find it weird that listeners are registered when they are not used in the end, while doing it my way I think it's more clear what happens.
For sub-requests, I'm not sure what you mean. In this instance, and in most response listeners I have seen, the sub-requests are always ignored anyway by the listener.
---------------------------------------------------------------------------
by drak at 2011/11/10 06:07:45 -0800
I don't see how loading up the dispatcher with a bunch of callables can be expensive - it's just loading an array basically.
Wouldn't it be better to have a separate `DispatcherAwareEvent extends Event`
class DispatcherAwareEvent extends Event
{
protected $dispatcher;
public function setDispatcher(EventDispatcher $dispatcher)
{
$this->dispatcher = $dispatcher;
}
public function getDispatcher()
{
return $this->dispatcher;
}
This can then be used as a base class for what you need `MyEvent extends DispatcherAwareEvent`
$event = new MyEvent($dispatcher, $foo);
$dispatcher->dispatch($event);
---------------------------------------------------------------------------
by Seldaek at 2011/11/10 06:18:57 -0800
@drak: Every event is part the event dispatching system and therefore should be aware of the dispatcher imo. It's not like the ContainerAwareInterface which is gluing things that do not especially have to know about the DIC together.
If we do that, then we have to start arguing every time we need the dispatcher in a given event, because the original author did not think it was necessary, and then that will only make it into the next minor version, etc. Not fun at all.
---------------------------------------------------------------------------
by drak at 2011/11/10 06:36:26 -0800
By the way, the event dispatchers looks to be pretty well optimized given the fact that it only sorts listeners if they are called, and then only once.
---------------------------------------------------------------------------
by drak at 2011/11/10 12:33:28 -0800
It just seems weird. I mean, following on, why isn't the event name a compulsory parameter also? - again, you can say both ways, if you need it, make it part of your custom Event class, or since it's a required param to be able to dispatch an event in the first place, make it part of the base Event class. All I'm saying it it seems suspicious when it could be achieved a different way.
For example, you could inject the dispatcher into the listener itself and then the event handler could access the dispatcher if it needs:
class MyListener
{
public function __construct(EventDispatcher $eventDispatcher)
{
//...
}
public function someListener(Event $event)
{
//...
}
}
---------------------------------------------------------------------------
by stof at 2011/11/10 15:20:07 -0800
@drak The issue when injecting the dispatcher in the listener is described in the issue: circular dependency: you need to create the dispatcher before the listener (as it is injected in it) and when the listener is not lazy-loaded (in Silex for instance), you need to create it before the dispatcher.
---------------------------------------------------------------------------
by drak at 2011/11/10 21:15:45 -0800
Indeed, although it might not unreasonable to expect to create the dispatcher first... but anyway I'm convinced!
Injecting the dispatcher could lead to some __very interesting possibilities__ as standard. While we are at it though, we should have a getter and setter for `$name` in the `Event` class and `$event->setName($eventname)` in the `dispatch()` method. Allowing an event to know it's name is very useful. It allows a single listener to be registered for multiple names, and even makes the event object reusable. I don't know why $name was removed, it was in the Symfony 1 dispatcher and while the new dispatcher is brilliant from an OO point of view, missing the name as standard is a big shame.
+1 from me.
Commits
-------
78883f9 Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}``
Discussion
----------
Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}`
Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}``
Bug fix: yes
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2424
---------------------------------------------------------------------------
by stof at 2011/10/18 07:44:48 -0700
@docteurklein still the same issue. github says it conflicts. Are you sure you fetched the latest version ?
Thus it should be sent to 2.0 IMO as it is a bugfix
---------------------------------------------------------------------------
by docteurklein at 2011/10/18 07:51:21 -0700
@stof Yes, i'm pretty sure I followed the patches sending flow. (http://symfony.com/doc/2.0/contributing/code/patches.html
My tools are telling me it's ok.
I then merged it into master without any problem, which is up to date with upstream.
Sorry for the inconvenience.
I'll try to send it to 2.0 branch.
---------------------------------------------------------------------------
by docteurklein at 2011/10/18 07:53:52 -0700
@stof, what's wrong with https://github.com/docteurklein/symfony/commits/ticket_2424 ?
---------------------------------------------------------------------------
by stof at 2011/10/18 08:28:21 -0700
hmm, seems like github has an issue when determining if it conflicts or not. It's sad
---------------------------------------------------------------------------
by henrikbjorn at 2011/10/20 09:49:56 -0700
Dosent this already work ? as classes are namespaces the / should be a \ i think ?
Works for routes at least.
The locale management does not require sessions anymore.
In the Symfony2 spirit, the locale should be part of your URLs. If this is the case
(via the special _locale request attribute), Symfony will store it in the request
(getLocale()).
This feature is now also configurable/replaceable at will as everything is now managed
by the new LocaleListener event listener.
How to upgrade:
The default locale configuration has been moved from session to the main configuration:
Before:
framework:
session:
default_locale: en
After:
framework:
default_locale: en
Whenever you want to get the current locale, call getLocale() on the request (was on the
session before).
Builds upon aead4a9836180cabae4d47fe27c634dcd79ac8f2, which prematurely removed request scoping from the assets templating helper in all cases. The helper need only be request-scoped if one or more request-scoped packages (e.g. PathPackages) are injected into it. This change makes it possible to utilize the assets helper outside of a request (e.g. during a console script).
To ensure that the assets helper is not assigned a request scope, all asset base URL's must be defined for all packages (default and any named) and both protocols: HTTP and SSL. The included test config fixtures concisely accomplish this by specifying a single HTTPS URL as the base URL for our default and named package, since FrameworkExtension's Configuration conveniently registers this URL for both protocols.
-- add missing files
-- tweak translation command files
-- dumpers are now responsive for writting the files
-- moved the twig extractor the bridge
-- clear temp files after unit tests
-- check the presence of dumper in translation writer
-- General cleaning of the code
-- clean phpDoc
-- fix PHPDoc
-- fixing class name in configuration
-- add unit tests for extractors (php and twig)
-- moved test to correct location
-- polish the code
-- polish the code
when esi is enabled and internal uris are generated for esi-tags, an
attribute-array consisting entirely of null-values isn't handled correctly.
The reason is that php's `http_build_query()`-method outputs an empty string
for such arrays:
http_build_query(array('foo' => '')) == 'foo='
http_build_query(array('foo' => null)) == ''
In the latter case, the generation of an URI in `HttpKernel::generateInternalUri()`
generates an URI that could not be matched by the corresponding route (ex.
`_internal/Controller/.html` opposed to `_internal/Controller/none.html` which
should be expected).
This commit adds a possible solution as well as a simple test for this issue.
Commits
-------
9bcce9f fix tests
fc4787a fix non-extensible router
Discussion
----------
Router fix
Right now, the router is hard to overwrite (you need always a compiler pass). This commit fixes this.
---------------------------------------------------------------------------
by fabpot at 2011/07/18 01:15:36 -0700
Why do you need a complier pass to override the router?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 01:47:47 -0700
How would you suggest to overwrite it?
Basically, I want to do something like this:
```yml
services:
router:
parent: router.default
class: MyClass
calls:
- [moreDeps, []]
```
---------------------------------------------------------------------------
by Seldaek at 2011/07/18 05:07:19 -0700
Then maybe we should somehow support redefining services with the same name while keeping the old one as parent, otherwise we need this foo.default for every service out there?
---------------------------------------------------------------------------
by fabpot at 2011/07/18 06:30:34 -0700
as @Seldeak said, why do that for the router and not all services?
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 06:38:39 -0700
I have designed the SecurityBundle this way where extension is encouraged.
---------------------------------------------------------------------------
by schmittjoh at 2011/07/18 11:15:57 -0700
I should add that this is mainly a problem for services where you still want to use the semantic configuration that is provided by the bundle. For services which are not configured by the extension, this is not so much of an issue.
Anyway, if you don't want to merge it, just close the PR. I have no problem with using a compiler pass.
---------------------------------------------------------------------------
by fabpot at 2011/07/18 11:55:11 -0700
We already have such a case with translator and translator.real. I will review the existing services to see where it makes sense to implement the same strategy.
---------------------------------------------------------------------------
by Seldaek at 2011/07/18 12:20:55 -0700
I guess you'd do it anyway, but we should pick a winner between .real and .default
---------------------------------------------------------------------------
by lsmith77 at 2011/07/18 12:26:52 -0700
I would prefer ".default" as ".real" always confused me.
Commits
-------
5d46e63 [Form] Add the FormHelper configuration
a43fad4 [Form] Improve unit tests for rendering
1cb2129 [FrameworkBundle][Form] Adding a cache to FormHelper::lookupTemplate()
f39ce67 [Form][FrameworkBundle] PHP theming
Discussion
----------
[2.1] RFC [Form] Php theming
This PR implements theming support for the php engine.
It works similarly as the twig theming with themes being folders and blocks being individual files.
There are probably a few things to tune before this can get merged:
### Theme naming
The current format is "\<Bundle\>:\<Controller\>" i.e. "FrameworkBundle:Form".
Is this ok or could you imagine something better ?
### Div and Table theme folders
Currently "FrameworkBundle\\Resources\\views\\Form" and "FrameworkBundle\\Resources\\views\\FormTable"
Is this ok or anything better ?
### Form helper configuration
I am not sure if the configuration is at the best possible location:
```
framework:
templating:
form:
resources: [themeA, themeB]
```
Any better idea ?
There is a [thread on the ml](http://groups.google.com/group/symfony-devs/browse_thread/thread/9b3f131fe116b511)
Commits
-------
2c1108c [Form] Revert the ability to override anything else than the text of the label while rendering a row
da467a6 [Form] Fix the exception message when no block is found while rendering
8670995 [Form] Optimize rendering when the block to render is known
41e07c9 [Form] Optimize rendering
ee5d975 [Form] Remove a test which is no more relevant (after recent FileType refactoring)
f729c6b [Form] Add the ability to override label & widget options when rendering a row
e09ae3f [Form][FrameworkBundle] Make FormHelper::renderSection() recursively callable, introduce FormHelper::renderBlock()
e43fb98 [Form][TwigBridge] Make FormExtension::render() recursively callable to ease theming
Discussion
----------
[Form] Some refactoring of the rendering
# First two commits
## FormExtension::render() can now be called recursively.
The main use case is theming support in for collections. Let's consider that you have a collection of `CustomType`, the type hierarchy while rendering the proto would be `field < form < custom < prototype`. Before this change any theme applied to your custom type (i.e. a `custom_row` block) would not have been taken into account while rendering the prototype because of the structure of the `prototype_row` block:
```html
{% block prototype_row %}
{% spaceless %}
<script type="text/html" id="{{ proto_id }}">{{ block('field_row') }}</script>
{% endspaceless %}
{% endblock prototype_row %}
```
which skip the `custom_row` block rendering to fallback to the `field_row` block rendering.
With this PR `prototype_row` recursively calls `FormExtension::render()`
```html
{% block prototype_row %}
{% spaceless %}
<script type="text/html" id="{{ proto_id }}">{{ form_row(form) }}</script>
{% endspaceless %}
{% endblock prototype_row %}
```
this has for effect to render the block for the parent type (i.e. `custom_row`)
## FormHelper
The `FormHelper` has been updated to more closely match the `FormExtension` architecture and the templates have been modified accordingly. `echo $view['form']->renderBlock(<block name>)` is the php equivalent of `{{ block(<block name>) }}`.
The attributes are now rendered using a template rather than by the `FormHelper::attributes()` method.
Several templates have been fixed.
# Third commit
The `$varStack` property was used to forward options to the label and the widget when rendering a row. The implementation was not working as expected. The proposed way to override label and widget options is to pass these options in the `label` and `widget` keys while callinf `render_row`.
That would be:
`{{ form_row(form.field, {"attr": {<row attributes>}, "label" : {"label": <text>, "attr": {<label attr>}}, "widget" : { "attr" : {<widget attributes}} } }}`
So there is now the ability to set attributes for the row (`<div>` or `<tr>`).
This has been discussed on [the mailing list](http://groups.google.com/group/symfony-devs/browse_thread/thread/17754128ba480545). **I would like to find a compromise with @Seldaek before this gets merged**
The `$varStack` property is now only used when recursively calling `FormExtension::render()`
# Notes
I have preferred to submit several commits in order to ease review and to keep some history.
---------------------------------------------------------------------------
by stof at 2011/06/20 05:20:56 -0700
@vicb On a side note, do you think it would be possible to support form theming in PHP templates too ? Currently, the only way to customize the rendering of forms when using PHP templates is to overwrite the FrameworkBundle's templates, and this impacts all forms. This makes the PHP rendering far less powerful than the Twig one.
I don't know the Form rendering and the PHPEngine well enough to know if it is feasible for 2.1 or not.
---------------------------------------------------------------------------
by vicb at 2011/06/20 05:35:11 -0700
@stof I hope to make it possible but I need a little bit more thinking to find the best possible solution which should not look like a hack.
---------------------------------------------------------------------------
by vicb at 2011/06/21 01:13:10 -0700
This should not be merged yet, it might have some issue with the variable stack. I am working on it.
---------------------------------------------------------------------------
by vicb at 2011/06/21 01:41:11 -0700
Sorted out the issue, it was linked to some local _optimization_, the code of this PR is ok.
---------------------------------------------------------------------------
by vicb at 2011/06/21 02:01:24 -0700
I have pushed a [POC of php theming based on this PR](https://github.com/vicb/symfony/commits/form%2Fphp-theme) to my repo - it is lacking a configuration and cache layer.
I have open [a thread on the ml](http://groups.google.com/group/symfony-devs/browse_thread/thread/9b3f131fe116b511) to discuss this.
---------------------------------------------------------------------------
by vicb at 2011/06/21 23:40:21 -0700
@fabpot fixed in the last commit.
Here are the new simplified rules:
* Required cache warmers are *always* executed when the Kernel boots for the first time;
* Optional cache warmers are *only* executed from the CLI via cache:warmup
These new rules means that all the configuration settings for the cache
warmers have been removed. So, if you want the best performance, remember to
warmup the cache when going to production.
This also fixed quite a few bugs.
* gordonslondon/http-foundation/response:
[HttpFoundation] merge Response::isRedirected() with Response::isRedirect() - Response::isRedirected() has been removed
* Seldaek/events:
[EventDispatcher] Removed temporary code
[FrameworkBundle] Improved code readability
[FrameworkBundle] Clarified code and fixed regression
Update Core and Security events to latest model
[EventDispatcher] Allow registration of arbitrary callbacks
[EventDispatcher] Remove useless code
[EventDispatcher] Minor memory optimization to getListeners()
[FrameworkBundle] Small optimization, remove some function calls
This in effect removes the direct link between event name and the method name on the handler.
Any callback can be given as a handler and the event name becomes an arbitrary string. Allowing for easier namespacing (see next commit)
The consequence of this commit is that variables are accessible that have been passed to a surrounding form helper.
Example template:
{% block my_widget_label %}
<label>{{ label }}
{% endblock %}
{% block my_widget_row %}
{# It is not necessary to explicitely pass through the label variable #}
{{ form_label(form) }}
{{ form_widget(form) }}
{% endblock %}
Example usage:
{{ form_row(form.mywidget, { 'label': 'My Widget' }) }}
* vicb/service-event:
[FrameworkBundle] Optimization of the method ContainerAwareEventDispacther::dispatch()
[FrameworkBundle] Fix an issue with ContainerAwareEventDispatcher when re-entering a scope
* made the options array only for "global" options that are valid for all session storages
* changed the PDO session storage constructor signature to accept an array of options for DB configuration
* changed the storage_id to be the full service id, instead of just part of it
* removed the class parameter for session as it can be changed via the .class parameter (it was the only example in the framework)
* removed the configuration for the PDO session storage for now
* vicb/event_debug:
[FrameworkBundle] Make some TraceableEventDispacther properties private
[Event] Tweak phpDoc for consistency
[FrameworkBundle] Add error detection to the TraceableEventDispatcher
* vicb/locate_template2:
[FrameworkBundle] Enforce templates instances of TemplateReferenceInterface
[FrameworkBundle] Add unit tests for the CacheTemplateLocator class
[FrameworkBundle] Add unit tests for the TemplateLocator class
[TwigBundle] Fix the cache warmer
[TwigBundle] Tweak cache warmer configuration
[FrameworkBundle] Fix resource inheritance in the template cache warmer
The parameter has been removed and the service moved to the XML file (for consistency).
The behavior is still the same as before as any non-public service
which is not referenced anywhere will be automatically removed by a
compiler pass.
Controllers:
"BlogBundle:Post:show" is now "Blog:Post:show"
Templates:
"BlogBundle:Post:show.html.twig" is now "Blog:Post:show.html.twig"
Resources:
"@BlogBundle/Resources/config/blog.xml" is now "@Blog/Resources/config/blog.xml"
Doctrine:
"$em->find('BlogBundle:Post', $id)" is now "$em->find('Blog:Post', $id)"
It's a detail, but it hits usability. For normal bundles (those without children), we're able to actually print the namespace where we're looking for the Controller. For bundles with children, this would be a very verbose message, but we can at least print all of the bundles that we looked inside of.
The onCore* events are fired at some pre-defined points during the
handling of a request. At this is more important than the fact
that you can change things from the event.
The only missing part is ContainerAwareEventManager::addEventSubscriberService(),
because I'm not sure how to find out the class name of a service in the DIC.
Also, inline documentation of this code needs to be finished once it is accepted.
Doctrine's EventManager implementation has several advantages over the
EventDispatcher implementation of Symfony2. Therefore I suggest that we
use their implementation.
Advantages:
* Event Listeners are objects, not callbacks. These objects have handler
methods that have the same name as the event. This helps a lot when
reading the code and makes the code for adding an event listener shorter.
* You can create Event Subscribers, which are event listeners with an
additional getSubscribedEvents() method. The benefit here is that the
code that registers the subscriber doesn't need to know about its
implementation.
* All events are defined in static Events classes, so users of IDEs benefit
of code completion
* The communication between the dispatching class of an event and all
listeners is done through a subclass of EventArgs. This subclass can be
tailored to the type of event. A constructor, setters and getters can be
implemented that verify the validity of the data set into the object.
See examples below.
* Because each event type corresponds to an EventArgs implementation,
developers of event listeners can look up the available EventArgs methods
and benefit of code completion.
* EventArgs::stopPropagation() is more flexible and (IMO) clearer to use
than notifyUntil(). Also, it is a concept that is also used in other
event implementations
Before:
class EventListener
{
public function handle(EventInterface $event, $data) { ... }
}
$dispatcher->connect('core.request', array($listener, 'handle'));
$dispatcher->notify('core.request', new Event(...));
After (with listeners):
final class Events
{
const onCoreRequest = 'onCoreRequest';
}
class EventListener
{
public function onCoreRequest(RequestEventArgs $eventArgs) { ... }
}
$evm->addEventListener(Events::onCoreRequest, $listener);
$evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
After (with subscribers):
class EventSubscriber
{
public function onCoreRequest(RequestEventArgs $eventArgs) { ... }
public function getSubscribedEvents()
{
return Events::onCoreRequest;
}
}
$evm->addEventSubscriber($subscriber);
$evm->dispatchEvent(Events::onCoreRequest, new RequestEventArgs(...));
The Response is not available in the DIC anymore.
When you need to create a response, create an instance of
Symfony\Component\HttpFoundation\Response instead.
As a side effect, the Controller::createResponse() and Controller::redirect()
methods have been removed and can easily be replaced as follows:
return $this->createResponse('content', 200, array('foo' => 'bar'));
return new Response('content', 200, array('foo' => 'bar'));
return $this->redirect($url);
return Response::createRedirect($url);
How to upgrade?
For XML configuration files:
* All extensions should now use the config tag (this is just a convention as
the YAML configurations files do not use it anymore):
* The previous change means that the doctrine and security bundles now are
wrapped under a main "config" tag:
<doctrine:config>
<doctrine:orm />
<doctrine:dbal />
</doctrine:config>
<security:config>
<security:acl />
...
</security:config>
For YAML configuration files:
* The main keys have been renamed as follows:
* assetic:config -> assetic
* app:config -> framework
* webprofiler:config -> web_profiler
* doctrine_odm.mongodb -> doctrine_mongo_db
* doctrine:orm -> doctrine: { orm: ... }
* doctrine:dbal -> doctrine: { dbal: ... }
* security:config -> security
* security:acl -> security: { acl: ... }
* twig.config -> twig
* zend.config -> zend
* Remove redundant null/true equivalent array() values for array nodes
* Profiler matcher should not be deep merged; subsequent configs can simply overwrite its array
* Per lsmith's suggestion, change "isset(x) && x" to "!empty(x)"
* Templating engines node should be required, which is necessary to ensure requiresAtLeastOneElement() applies to its prototype children
In routing files, import statements allow an optional "type" option to hint the resources' type (e.g. for ambiguous file extensions). This adds the same type option to the FrameworkExtension config, which defines the main routing resource.
This reverts commit f53080860a.
Revert "[Router] config fixes"
This reverts commit 51beecc6f2.
Revert "moved duplicated files to a new Config component"
This reverts commit a8ec9b27f0.
This fixes some BC problems introduced in f9138d313b. Some top-level can now be simply enabled by providing true/null in PHP/YAML. Additionally, the Configuration\Builder allows options to be unset by providing "false" (helpful for overriding activation in a previous config file). All options supporting these behaviors can be found in the Configuration.php file (look for canBeUnset() and treatNull/TrueLike()).
Major changes:
* Removed "enabled" option for profiler config. Profiler is now enabled if its config is true, null or a map.
* Restore original config structure for validation namespaces. In PHP/YAML, namespaces are defined under annotations as an alternative to false (disabled) and true/null (enabled). For XML, annotation remains a boolean attribute for validation and a one or more optional namespace tags may appear within <app:validation />. During config normalization, namespace tags under validation will be moved to annotations to conform to the PHP/YAML structure (this occurs transparently to the user).
* Restore behavior for router/templating config sections being optional (as shown in changes to session/validation test fixtures). If either top-level section is unset in the configuration, neither feature will be enabled and the user will no longer receive exceptions due to missing a resource option (router) or engines (templating). Resource/engines will still be properly required if the respective feature is enabled.
* Remove unused router type option from XML config XSD. Type is only relevant for import statements, so this option is likely useless.
Additional small changes:
* Added isset()'s, since config options may be unset
* Wrap registerXxxConfiguration() calls in isset() checks
* Load translation.xml in configLoad(), since it's always required
* Default cache_warmer value (!kernel.debug) is determined via Configuration class
Things to be fixed:
* Configuration\Builder doesn't seem to respect isRequired() and requiresAtLeastOneElement() (or I haven't set it properly); this should replace the need for FrameworkExtension to throw exceptions for bad router/templating configs
* The config nodes for session options don't have the "pdo." prefix, as dots are not allowed in node names. To preserve BC for now, the "pdo." prefix is still allowed (and mandated by XSD) in configuration files. In the future, we may just want to do away with the "pdo." prefix.
* Translator has an "enabled" option. If there's no use case for setting "fallback" independently (when "enabled" is false), perhaps "enabled" should be removed entirely and translator should function like profiler currently does.
* Profiler matcher merging might need to be adjusted so multiple configs simply overwrite matcher instead of merging its array keys.
Restructured config format to make processing more straightforward. Important changes that might break existing configs:
* Added "enabled" option for translator (improves multi-format compat)
* Removed hash variation of validation annotations option (only boolean)
* Moved namespace option directly under validation (improves multi-format compat)
The new merge process depends on an internal array of all supported options and their default values, which is used for both validating the config schema and inferring how to merge options (as an added benefit, it helps make the extension self-documenting). Exceptions will now be thrown for merge errors resulting from unrecognized options or invalid types. Since incoming configurations are all merged atop the defaults, many isset() checks were removed. As a rule of thumb, we probably only want to ignore null values when an option would be used to set a parameter.
Also:
* Added missing attributes to symfony-1.0.xsd
* profiler: added only-exceptions attribute
* session: fix types and add pdo attributes
* Create FrameworkExtension tests with PHP/XML/YAML fixtures
* Use "%" syntax instead of calling getParameter() within FrameworkExtension
* Normalize config keys and arrays with helper methods for PHP/XML/YAML compatibility
Earlier changes:
* Remove nonexistent "DependencyInjection/Resources/" path from XmlFileLoaders
* Remove hasDefinition() checks, as register methods should only execute once
* Remove first-run logic from registerTranslatorConfiguration(), as it is only run once
* Removed apparently obsolete clearTags() calls on definitions for non-enabled features
You must now explicitly register the templating engine you want to use:
<app:templating>
<app:engine id="twig" />
</app:templating>
app.templating:
engines: ['twig']
Symfony2 comes with two such engines: 'twig', and 'php'.
