This PR was squashed before being merged into the master branch (closes#6014).
Commits
-------
2b13760 [Filesystem] [mirror] added "delete" option
Discussion
----------
[Filesystem] [mirror] added "delete" option
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets:
Todo: -
License of the code: MIT
Documentation PR: symfony/symfony-docs#123
I added a "delete" option to the mirror function. If set to true, then
files present in target dir and not in origin dir will be removed.
Added also unit test for these feature.
---------------------------------------------------------------------------
by pborreli at 2012-11-16T00:58:19Z
Symfony2 code standard use lowercase `true` and `false`
---------------------------------------------------------------------------
by mylen at 2012-11-16T20:25:19Z
I have problem to believe that the last commit (merging two if together) was to blame for the segfault on travis...
when I run the unit testing on my machine, I get:
I'm using PHP 5.4.7 by the way...
Time: 2 seconds, Memory: 3.25Mb
OK, but incomplete or skipped tests!
Tests: 80, Assertions: 106, Skipped: 14.
---------------------------------------------------------------------------
by pborreli at 2012-11-16T20:38:40Z
Can you fix end-of-lines ?
---------------------------------------------------------------------------
by mylen at 2012-11-16T20:52:37Z
I put UNIX line feed and UTF8 charset
---------------------------------------------------------------------------
by mylen at 2012-11-16T20:53:59Z
Sorry, I add to clone the symfony repo with github and did small editing using pspad, I forgot to setup charset and line feed...
* 2.1:
fixed CS
fixed CS
[Security] fixed path info encoding (closes#6040, closes#5695)
[HttpFoundation] added some tests for the previous merge and removed dead code (closes#6037)
Improved Cache-Control header when no-cache is sent
removed unneeded comment
Fix to allow null values in labels array
fix date in changelog
removed the Travis icon (as this is not stable enough -- many false positive, closes#6186)
Revert "merged branch gajdaw/finder_splfileinfo_fpassthu (PR #4751)" (closes#6224)
Fixed a typo
Fixed: HeaderBag::parseCacheControl() not parsing quoted zero correctly
[Form] Fix const inside an anonymous function
[Config] Loader::import must return imported data
[DoctrineBridge] Fixed caching in DoctrineType when "choices" or "preferred_choices" is passed
[Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
[HttpFoundation] fixed a small regression
Conflicts:
src/Symfony/Component/HttpFoundation/Tests/Session/Storage/Handler/MongoDbSessionHandlerTest.php
* 2.0:
fixed CS
removed the Travis icon (as this is not stable enough -- many false positive, closes#6186)
[Config] Loader::import must return imported data
[HttpFoundation] fixed a small regression
Conflicts:
README.md
src/Symfony/Bridge/Twig/Extension/FormExtension.php
src/Symfony/Bundle/FrameworkBundle/Resources/views/Form/attributes.html.php
src/Symfony/Bundle/FrameworkBundle/Resources/views/Form/form_widget.html.php
src/Symfony/Bundle/FrameworkBundle/Templating/Helper/FormHelper.php
src/Symfony/Component/Form/Form.php
src/Symfony/Component/HttpFoundation/Request.php
src/Symfony/Component/HttpFoundation/SessionStorage/PdoSessionStorage.php
tests/Symfony/Tests/Bridge/Doctrine/Logger/DbalLoggerTest.php
This PR was squashed before being merged into the master branch (closes#6232).
Commits
-------
7428bf9 [WebProfilerBundle] Some eye candy for deprecated calls
Discussion
----------
[WebProfilerBundle] Some eye candy for deprecated calls
.
@fabpot is [`|raw`](https://github.com/symfony/symfony/pull/new/deprecated#L0R117) a twig defect ?
---------------------------------------------------------------------------
by Baachi at 2012-12-08T09:12:12Z
Really nice 👍
---------------------------------------------------------------------------
by vicb at 2012-12-11T10:00:24Z
should be ready now
This PR was merged into the master branch.
Commits
-------
5d98fb1 [HttpKernel] ExceptionHandler is actually displaying PHP errors
Discussion
----------
[HttpKernel] ExceptionHandler is actually displaying all PHP errors
So there is no need to set display_errors to true in that case.
Partially fixes#6254.
This PR was merged into the master branch.
Commits
-------
abe244f [TwigBundle] Fixed tests on windows
Discussion
----------
[TwigBundle] Fixed tests on windows
This PR was merged into the master branch.
Commits
-------
f48b22a Added configuration pass that adds Twig Loaders
Discussion
----------
[Twig] [DI Pass] Added configuration pass that adds Twig Loaders
Bug fix: [no]
Feature addition: [yes]
Backwards compatibility break: [no]
Symfony2 tests pass: [yes]
Todo: Documentation?
License of the code: MIT
- Defined new Chain loader service with symfony Filesystem loader added
by default.
- Added compiler class which picks up any services tagged "twig.loader"
- If there are any instances of "twig.loader" the "twig.loader" alias is
set to the Twig_Loader_Chain service ID instead of the filesystem
loader.
I think I still like the explicitness of the other pull request, but I defer to your judgment :) This is certainly much easier for the developer.
---------------------------------------------------------------------------
by dantleech at 2012-12-03T08:31:08Z
Will update the PR later today / tomorrow
---------------------------------------------------------------------------
by dantleech at 2012-12-03T18:19:09Z
ok, updated. I throw a `Symfony\Component\DependencyInjection\Exception\LogicException` if there are no loaders -- not sure if that is the best thing to do, or if that is the best exception.
---------------------------------------------------------------------------
by fabpot at 2012-12-05T15:28:24Z
Looks good to me. Can you add a note in the CHANGELOG about this new possibility and update the documentation accordingly? Thanks.
---------------------------------------------------------------------------
by dantleech at 2012-12-05T17:50:37Z
ok. updated change log and changed both count() comparisons to be strict. @fabpot which documentation should I update? or should I add `cookbook/templating/registering_multiple_loaders.rst`?
---------------------------------------------------------------------------
by stof at 2012-12-05T20:07:37Z
@dantleech at least the DIC tags reference need to be updated to mention the new tag. I'm not sure a dedicated article is needed for it (but @weaverryan will decide if it is worth it)
---------------------------------------------------------------------------
by dantleech at 2012-12-06T17:57:20Z
Made a PR for documentation: https://github.com/symfony/symfony-docs/pull/2005
---------------------------------------------------------------------------
by dantleech at 2012-12-07T16:44:00Z
ok. have updated the correct CHANGELOG and squashed to one commit
Since even fatal errors are catched and turned into exceptions by
ErrorHandler, all PHP errors can nicely be displayed by
ExceptionHandler. There is no need to set display_errors to true
anymore then.
Partially fixes#6254 on github.
This PR was squashed before being merged into the master branch (closes#6253).
Commits
-------
e62b5f7 [Finder] cleanup, fixes, improvements
Discussion
----------
[Finder] cleanup, fixes, improvements
This PR was merged into the master branch.
Commits
-------
e458600 [DependencyInjection] Add deleted argument in Extension::processConfiguration
Discussion
----------
[DependencyInjection] Add deleted argument in Extension::processConfigur...
...ation
This PR was merged into the master branch.
Commits
-------
76e5bce no need to set the compiled route to null when cloning
Discussion
----------
[Routing] no need to set the compiled route to null when cloning
The compiled reference can be reused when cloning. When the route is changed, the compiled reference is set to null anyway. So if you just clone the route, this improves performance as it does not need to recompile.
When having a Cache-Control header like:
max-age="0"
isset($match[2]) is true but $match[2] containing: "0", it is evaluated
as false and 'true' will be set to "max-age" entry instead of "0".
This PR was merged into the master branch.
Commits
-------
cc0be8e [Finder] fluid, calling in() not required after append()
Discussion
----------
[Finder] fluid, calling in() not required after append()
- Added compiler class which picks up any services tagged "twig.loader"
- If there is one loader registered we set the alias to this loader
- If there is more than one we set the alias to a chain loader and all
the loaders to it
- If there is no loaders we throw an Exception
This PR was merged into the 2.1 branch.
Commits
-------
6e7e08f [Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
Discussion
----------
[Form] Fixed the "format" option in DateType
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #6141
Todo: -
License of the code: MIT
Documentation PR: -
This PR fixes a regression introduced in #4839. To quote that PR:
> This PR changes DateType and DateTimeType to support HTML5 by default when setting the option "widget" to "single_text".
In reality, the "format" option now defaults to the HTML5 format always, not just when "widget" is "single_text". This is fixed here.
The second commit in this PR removes special characters between select/text fields. What, with German locale, was
```
<day input>.<month input>.<year input>
```
before is now
```
<day input><month input><year input>
```
This is the way date fields are represented on the majority of websites. If you *need* separators, you can have them by setting the "format" option to a custom value:
```php
$builder->add('myDate', 'date', array(
'format' => 'dd.MM.yyyy',
));
```
---------------------------------------------------------------------------
by fabpot at 2012-12-07T08:52:21Z
The second commit should probably be done on master and it changes the behavior.
---------------------------------------------------------------------------
by bschussek at 2012-12-07T12:23:22Z
Ok, I removed the second commit now and removed the entries from the CHANGELOG.
This PR was merged into the master branch.
Commits
-------
d7a1154 make it possible for bundles extensions to prepend settings into the application configuration of any Bundle
Discussion
----------
[2.2] add possibility for bundles extensions to prepend the app configs
Bug fix: #4652
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
As can be seen in the patch the extensions that should prepend the configuration are enabled automatically if they implement ``PrependExtensionInterface``.
Just as an example, here an extension, which checks if SonataAdminBundle is available and if not disables integration with it in several Bundles. It also sets some default settings for ``document_class`` and ``default_document_manager_name``:
```
diff --git a/DependencyInjection/SymfonyCmfCoreExtension.php b/DependencyInjection/SymfonyCmfCoreExtension.php
index 9f92410..c0a8dbb 100644
--- a/DependencyInjection/SymfonyCmfCoreExtension.php
+++ b/DependencyInjection/SymfonyCmfCoreExtension.php
@@ -3,11 +3,12 @@
namespace Symfony\Cmf\Bundle\CoreBundle\DependencyInjection;
use Symfony\Component\HttpKernel\DependencyInjection\Extension;
+use Symfony\Component\\DependencyInjection\PrependExtensionInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Loader\XmlFileLoader;
use Symfony\Component\Config\FileLocator;
-class SymfonyCmfCoreExtension extends Extension
+class SymfonyCmfCoreExtension extends Extension implements PrependExtensionInterface
{
public function load(array $configs, ContainerBuilder $container)
{
@@ -15,4 +16,45 @@ class SymfonyCmfCoreExtension extends Extension
$loader->load('config.xml');
$loader->load('services.xml');
}
+
+ public function prepend(ContainerBuilder $container)
+ {
+ $bundles = $container->getParameter('kernel.bundles');
+ if (!isset($bundles['SonataDoctrinePHPCRAdminBundle'])) {
+ // disable SonataDoctrinePHPCRAdminBundle admin support in Bundles
+ $config = array('use_sonata_admin' => false);
+ foreach ($container->getExtensions() as $name => $extension) {
+ switch ($name) {
+ case 'symfony_cmf_menu':
+ case 'symfony_cmf_routing_extra':
+ case 'symfony_cmf_simple_cms':
+ $container->prependExtensionConfig($name, $config);
+ break;
+ }
+ }
+ }
+
+ // process the configuration of SymfonyCmfCoreExtension
+ $configs = $container->getExtensionConfig($this->getAlias());
+ $config = $this->processConfiguration(new Configuration(), $configs);
+ // add the default configs to various Bundles
+ foreach ($container->getExtensions() as $name => $extension) {
+ switch ($name) {
+ case 'symfony_cmf_content':
+ case 'symfony_cmf_simple_cms':
+ $container->prependExtensionConfig($name, $config);
+ break;
+ }
+ }
+ }
}
```
---------------------------------------------------------------------------
by stof at 2012-09-21T21:10:00Z
I think you are giving too much power to bundles here: a bundle becomes able to modify all the config defined explicitly by the user if it wants to do it.
I think it would be safer to give them the possibility to load an additional config file which would be prepended (so that user-defined config would still win). Giving the ability to load files means passing the loader used by the kernel, and it should then be called before calling the load method on the kernel itself (to respect the order of loaded files)
---------------------------------------------------------------------------
by lsmith77 at 2012-09-22T05:50:08Z
Not sure how a config file helps solve anything. I mean they can load as many config files as they want already. The key is being able to automatically apply configuration to multiple Bundles as well as enabling/disabling features based on if certain Bundles are registered.
BTW the end result in my examples is also prepended, so that user config wins. However yes this would be up to the person implementing the Bundle. We could however provide a dedicated method for prepending in addition to or instead of ``setExtensionConfig``.
---------------------------------------------------------------------------
by stof at 2012-09-22T11:40:29Z
@lsmith77 If you can load a file with the main loader, this file can provide some app-level configuration (be it for your own bundle or others).
And your code example is indeed prepending. But imagine what would occur when someone uses this feature without knowing well how the component works: he will likely call ``setExtensionConfig`` in a first implementation, thus dropping all userland config for the bundle. Your setup does not only allow to make a file win over the userland config but makes it even easier to remove the userland config.
---------------------------------------------------------------------------
by lsmith77 at 2012-09-22T18:11:29Z
but i dont get how that would help. the point is to be able for one bundle to configure other bundles before the load as this is obviously alot cleaner than trying to do the same via a compiler pass. so imho this is what is needed to encourage decoupled bundles. otherwise for example CMS or other reuseable and extensible apps will be forced to always put everything in one bundle.
---------------------------------------------------------------------------
by stof at 2012-09-22T19:23:45Z
@lsmith77 I agree about the feature, not about the way to implement it. If you allow bundles to load a file as it it were some app-level config, they would become able to provide some config for other bundles (and you could load several files depending of which bundles are enabled), but without allowing bundles to remove the userland config.
---------------------------------------------------------------------------
by lsmith77 at 2012-09-22T19:50:19Z
sorry but i dont understand what you suggest. more over i dont see the problem. its already possible to seriously break stuff with compiler passes which cannot be easily enabled/disabled. this is just convenience. if it doesnt work because of some obscure combo then simply dont use it for the app since it needs to be explicitly enabled in the kernel.
---------------------------------------------------------------------------
by lsmith77 at 2012-09-24T09:25:10Z
@stof thought about your comments, are you suggesting for a Bundle to be able to generate a config file that is prepended? in that case the current behavior would already be that if we change ``setExtensionConfig`` to just be a ``prependExtensionConfig`` .. however i am not sure if we really need this limitation since as i point out this would still by far be less dangerous than compiler passes and also i expect this to be used mainly by open source applications on top of Symfony2 rather than standard bundles.
---------------------------------------------------------------------------
by lsmith77 at 2012-10-13T13:28:29Z
@lolautruche i also think this is relevant for you guys. this way you could start preconfiguring 3rd party bundles as part of your main ezPublish bundle.
---------------------------------------------------------------------------
by lolautruche at 2012-10-13T13:57:09Z
While I suspect a nice feature, the implementation looks obscure to me...
---------------------------------------------------------------------------
by lsmith77 at 2012-10-13T17:43:02Z
The implementation of the example extension or the implementation of the actual changes proposed in this PR?
---------------------------------------------------------------------------
by lolautruche at 2012-10-13T17:46:57Z
The example, sorry 😃
---------------------------------------------------------------------------
by lsmith77 at 2012-10-13T17:50:38Z
The example was fairly quickly hacked together. The basic thing you need to do is fetch the config for the bundle you want to change, manipulate the config (usually by appending an array to the array of configs so that you dont affect explicit configuration) and then set it again.
As I explained to @stof it would alternative/additionally be possible to support a method that pushes a config array to the top of the array of config stack. Such a method might make the necessary code simpler.
---------------------------------------------------------------------------
by stof at 2012-10-13T21:39:07Z
@fabpot what do you think about it ?
---------------------------------------------------------------------------
by jrobeson at 2012-10-20T15:45:18Z
I've been porting much of an existing framework over to use more symfony components and bundles. I think that this might help some of the problems i've been having. I would really appreciate some better examples as how to one would use it (same for the cmf router, but that's another story).
---------------------------------------------------------------------------
by lsmith77 at 2012-10-21T07:28:52Z
not really sure what other examples i could give. the process is quite simple:
1) determine what configuration options to add to other Bundles
for example with the following code I determine that SonataAdmin for PHPCR is not installed (which means i should disable using it in other Bundles):
```
$bundles = $container->getParameter('kernel.bundles');
if (!isset($bundles['SonataDoctrinePHPCRAdminBundle'])) {
```
alternatively I could simply already process the configuration and then pick all or some of these configuration options:
```
$configs = $container->getExtensionConfig($this->getAlias());
$config = $this->processConfiguration(new Configuration(), $configs);
```
2) then add these configuration to what other Bundles I feel should get these options
usually I will add these to the top of the config array stack. this means that if the user would manually set the same setting in most cases the user setting will override what the pre-processor set.
```
$container->unshiftExtensionConfig($name, array('use_sonata_admin' => false));
```
---------------------------------------------------------------------------
by lsmith77 at 2012-10-24T12:52:38Z
added ``ContainerBuilder::unshiftExtensionConfig`` since this is the usual use case. with this method added it could be discussed if ``ContainerBuilder::setExtensionConfig`` is still needed or not.
---------------------------------------------------------------------------
by lsmith77 at 2012-11-24T14:48:44Z
I spoke to @fabpot today and he said that since this patch just allows you to set defaults and not really "process" the actual configuration I shouldn't call it "preProcess" so I renamed it to "prepend".
Furthermore as its just prepending @fabpot said there isnt really a need to require manually enabling it, so here is a patch to auto-enable the prepending logic:
```
diff --git a/src/Symfony/Component/HttpKernel/Kernel.php b/src/Symfony/Component/HttpKernel/Kernel.php
index b890fbf..7374b87 100644
--- a/src/Symfony/Component/HttpKernel/Kernel.php
+++ b/src/Symfony/Component/HttpKernel/Kernel.php
@@ -701,8 +701,8 @@ abstract class Kernel implements KernelInterface, TerminableInterface
*/
protected function prependExtensionConfigs(ContainerBuilder $container)
{
- foreach ($this->getPrependingExtensions() as $name) {
- $extension = $container->getExtension($name);
+ foreach ($this->bundles as $bundle) {
+ $extension = $bundle->getContainerExtension();
if ($extension instanceof PrependExtensionInterface) {
$extension->prepend($container);
}
@@ -710,16 +710,6 @@ abstract class Kernel implements KernelInterface, TerminableInterface
}
/**
- * Returns the ordered list of extensions that may prepend extension configurations.
- *
- * @return array
- */
- protected function getPrependingExtensions()
- {
- return array();
- }
-
- /**
* Gets a new ContainerBuilder instance used to build the service container.
*
* @return ContainerBuilder
```
---------------------------------------------------------------------------
by lsmith77 at 2012-11-25T19:31:01Z
ok .. i pondered the code some more and now i have enabled registering of the prepending extensions by default, since its now quite easy to just override the ``prependExtensionConfigs()`` method since there is almost no logic in there anymore.
@fabpot i am not 100% sure with the naming yet ..
---------------------------------------------------------------------------
by lsmith77 at 2012-12-05T14:03:43Z
@fabpot if you are ok with the PR as it is now, i can do the rebase so you can merge this?
---------------------------------------------------------------------------
by lsmith77 at 2012-12-05T18:30:29Z
@fabpot all good now? then i will squash the commits ..
---------------------------------------------------------------------------
by lsmith77 at 2012-12-05T18:34:50Z
actually looking at the full change set again i am no longer sure if it makes sense to have ``PrependExtensionInterface`` in the DI rather than the HttpKernel.
---------------------------------------------------------------------------
by lsmith77 at 2012-12-07T09:21:14Z
@fabpot all good now?
---------------------------------------------------------------------------
by fabpot at 2012-12-07T09:37:52Z
The code looks good to me now. There are two remaining task before merging:
* Is it something we need to add somewhere in the documentation?
* Can you add a note in the DI component CHANGELOG?
Thanks.
---------------------------------------------------------------------------
by lsmith77 at 2012-12-07T09:49:17Z
i have added a changelog entry and squashed the commits.
i will also work on a documentation entry, i guess i will make it a cookbook entry. not sure if it should be included in http://symfony.com/doc/2.0/cookbook/bundles/extension.html .. but imho it would better be a separate entry.
* 2.1:
[HttpFoundation] changed UploadedFile::move() to use move_uploaded_file() when possible (closes#5878, closes#6185)
[HttpFoundation] added a check for the host header value
[DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option
[DoctrineBridge] Improved exception message
[DoctrineBridge] Fixed: Exception is thrown if the entity class is not known to Doctrine
Removed useless branch alias for dev-master in composer.json
Conflicts:
composer.json
src/Symfony/Bridge/Doctrine/composer.json
src/Symfony/Bridge/Monolog/composer.json
src/Symfony/Bridge/Propel1/composer.json
src/Symfony/Bridge/Swiftmailer/composer.json
src/Symfony/Bridge/Twig/composer.json
src/Symfony/Bundle/FrameworkBundle/composer.json
src/Symfony/Bundle/SecurityBundle/composer.json
src/Symfony/Bundle/TwigBundle/composer.json
src/Symfony/Bundle/WebProfilerBundle/composer.json
src/Symfony/Component/BrowserKit/composer.json
src/Symfony/Component/ClassLoader/composer.json
src/Symfony/Component/Config/composer.json
src/Symfony/Component/Console/composer.json
src/Symfony/Component/CssSelector/composer.json
src/Symfony/Component/DependencyInjection/composer.json
src/Symfony/Component/DomCrawler/composer.json
src/Symfony/Component/EventDispatcher/composer.json
src/Symfony/Component/Filesystem/composer.json
src/Symfony/Component/Finder/composer.json
src/Symfony/Component/Form/composer.json
src/Symfony/Component/HttpFoundation/composer.json
src/Symfony/Component/HttpKernel/composer.json
src/Symfony/Component/Locale/composer.json
src/Symfony/Component/OptionsResolver/composer.json
src/Symfony/Component/Process/composer.json
src/Symfony/Component/Routing/composer.json
src/Symfony/Component/Security/composer.json
src/Symfony/Component/Serializer/composer.json
src/Symfony/Component/Templating/composer.json
src/Symfony/Component/Translation/composer.json
src/Symfony/Component/Validator/composer.json
src/Symfony/Component/Yaml/composer.json
* 2.0:
[HttpFoundation] changed UploadedFile::move() to use move_uploaded_file() when possible (closes#5878, closes#6185)
[HttpFoundation] added a check for the host header value
Conflicts:
src/Symfony/Component/HttpFoundation/File/File.php
src/Symfony/Component/HttpFoundation/Request.php
src/Symfony/Component/HttpFoundation/Tests/RequestTest.php
This PR was merged into the 2.0 branch.
Commits
-------
0489799 [HttpFoundation] added a check for the host header value
Discussion
----------
[HttpFoundation] added a check for the host header value
alternative for #3865
This PR was squashed before being merged into the master branch (closes#6005).
Commits
-------
577ee80 [HttpFoundation] Move IP check methods to a HttpUtils class for reuse
Discussion
----------
[HttpFoundation] Move IP check methods to a HttpUtils class for reuse
---------------------------------------------------------------------------
by vicb at 2012-11-13T18:05:18Z
Thanks @stof ! (didn't get my copy paste error as PHP allow calling non static method w/o a warning).
---------------------------------------------------------------------------
by GromNaN at 2012-11-17T23:19:29Z
Having an `Utils` class with mixed functions doesn't seem to be a good practice. I think the class should be called something like `Symfony\Component\HttpFoundation\IpAddress`.
---------------------------------------------------------------------------
by vicb at 2012-11-27T09:37:20Z
@fabpot could this be merged if `HttpUtils` is renamed to `IpUtils` ?
---------------------------------------------------------------------------
by fabpot at 2012-12-06T13:35:28Z
Renaming the class to `IpUtils` is indeed a good idea.
---------------------------------------------------------------------------
by vicb at 2012-12-06T14:07:59Z
ready !
---------------------------------------------------------------------------
by fabpot at 2012-12-06T14:39:19Z
Can you add an entry in the CHANGELOG?
---------------------------------------------------------------------------
by vicb at 2012-12-06T14:53:09Z
done, thanks for the reminder !
This PR was merged into the 2.1 branch.
Commits
-------
b604eb7 [DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option
db2ee54 [DoctrineBridge] Improved exception message
99321cb [DoctrineBridge] Fixed: Exception is thrown if the entity class is not known to Doctrine
Discussion
----------
[DoctrineBridge] fixed caching when EntityType is used with the "query_builder" option
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: -
This PR was squashed before being merged into the master branch (closes#6207).
Commits
-------
57e9d28 [DI] Add a base class for extension
Discussion
----------
[DI] Add a base class for extension
depends on #6148
@fabpot should we change `addClassesToCompile` & the likes (thinking of traits).
---------------------------------------------------------------------------
by fabpot at 2012-12-06T13:05:05Z
Can you rebase?
---------------------------------------------------------------------------
by fabpot at 2012-12-06T13:06:43Z
hmmm, now that I see the result, I'm not sure it is worth it as the Extension class in the DI component depends on the Config one.
---------------------------------------------------------------------------
by vicb at 2012-12-06T13:23:29Z
No pb, I can remove it, should I remove the `ContainerBuilder` altogether ?
---------------------------------------------------------------------------
by fabpot at 2012-12-06T13:37:18Z
I would keep everything that is strictly in the DI namespace in the DI extension class and everything else in the HttpKernel class as it is now.
---------------------------------------------------------------------------
by vicb at 2012-12-06T13:38:59Z
But this change is **great** if you need the DI without the full stack.
What about my other comment ?
---------------------------------------------------------------------------
by fabpot at 2012-12-06T13:55:30Z
Which other comment? This one? "should I remove the ContainerBuilder altogether?" In which case, I don't understand what it means.
What about adding 2 classes in the DI component: the base one and another one with the dependency on the config component? Is it overkill?
---------------------------------------------------------------------------
by vicb at 2012-12-06T14:06:43Z
> "should I remove the ContainerBuilder altogether?"
I mean that the **widely used** (ie loaders) `ContainerBuilder` also depends on Config - that was kind of a joke !
I was refering to my first comment here
> should we change addClassesToCompile & the likes (thinking of traits).
Overkill I don't know but useless for sure: the `ExtensionInterface` depends on `ContainerBuilder` which depends on `Config`.
