* 2.8: (61 commits)
[Debug] Fix ClassNotFoundFatalErrorHandler candidates lookups
[2.6][Translator] Extend, refactor and simplify Translator tests.
[VarDumper] Allow preserving a subset of cut arrays
[Console] Bind the closure (code) to the Command if possible
[VarDumper] Added support for SplFileObject
[VarDumper] Added support for SplFileInfo
Update DebugClassLoader.php
inject asset packages in assets helper service
[travis] Do not exclude legacy tests on 2.7
[HttpFoundation] remove getExtension method
[2.6][Translation] fix legacy tests.
[Form] Removed remaining deprecation notices in the test suite
[Form] Moved deprecation notice triggers to file level
[Debug] Map PHP errors to LogLevel::CRITICAL
[FrameworkBundle][Server Command] add address port number option.
[Routing][DependencyInjection] Support .yaml extension in YAML loaders
[DX] improve file loader error for router/other resources in bundle
[FrameworkBundle] Initialize translator with the default locale.
[FrameworkBundle] Fix Routing\DelegatingLoader resiliency to fatal errors
[2.7][Translation] remove duplicate code for loading catalogue.
...
Conflicts:
composer.json
src/Symfony/Bridge/Swiftmailer/composer.json
src/Symfony/Component/Console/Helper/DialogHelper.php
src/Symfony/Component/Debug/ErrorHandler.php
src/Symfony/Component/Debug/Tests/FatalErrorHandler/ClassNotFoundFatalErrorHandlerTest.php
src/Symfony/Component/Form/Extension/HttpFoundation/EventListener/BindRequestListener.php
src/Symfony/Component/Locale/composer.json
This PR was merged into the 3.0-dev branch.
Discussion
----------
[Routing] remove deprecations for 3.0
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | no
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | no, but unrelated
| Fixed tickets |
| License | MIT
| Doc PR |
Commits
-------
f939fea [Routing] make path required again in the xsd
82d54fa [FramworkBundle] our tests now expect symfony 3.0 behavior for routing
4ca9ab3 [FrameworkBundle] remove deprecated routing features
86278cd [Routing] remove deprecated features from routing
This PR was squashed before being merged into the 2.7 branch (closes#12960).
Discussion
----------
[FrameworkBundle] Container parameters in Route#condition
| Q | A
| ------------- | ---
| Bug fix? | no
| New feature? | yes
| BC breaks? | yes
| Deprecations? | no
| Tests pass? | no
| Fixed tickets | -
| License | MIT
| Doc PR | -
Adds ability to use parameters in route conditions like you can use them in container definitions:
```php
contact:
path: /contact
defaults: { _controller: AcmeDemoBundle:Main:contact }
condition: "request.headers.get('User-Agent') matches '%allowed_user_agents%'"
```
As you could see replacement of the placeholder happens before ExpressionLanguage will tokenize and compile the expression so it looks kinda ad-hoc and primitive. This means a BC break for us, because some of conditions out there that had percentage symbol might be invalid now, f.e.: `10%var_name%2`- without the patch this will be currently compiled to `10 % $var_name % 2`, with the patch it will try to replace `%var_name%` with a parameter. The same goes for percentage symbols inside string literals.
This PR is a different implementation of #12869 which is I think is too overcomplicated for this feature.
Commits
-------
505e474 [FrameworkBundle] Container parameters in Route#condition
This PR was merged into the master branch.
Discussion
----------
unify constructor initialization style throughout symfony
| Q | A
| ------------- | ---
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | n/a
In almost all classes symfony uses property initialization when the value is static. Constructor initialization is only used for things that actually have logic, like passed parameters or dynamic values. IMHO it makes the code much more readable because property definition, phpdoc and default value is in one place. Also one can easily see what the constructor implements for logic like overridden default value of a parent class. Otherwise the real deal is just hidden behind 10 property initializations. One more advantage is that it requires less code. As you can see, the code was almost cut in half (210 additions and 395 deletions).
I unified it accordingly across symfony. Sometimes it was [not even consistent within one class](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Config/Definition/BaseNode.php#L32). At the same time I recognized some errors like missing parent constructor call, or undefined properties or private properties that are not even used.
I then realized that a few Kernel tests were not passing because they were deeply implementation specific like modifying booted flag with a custom `KernelForTest->setIsBooted();`. I improved and refactored the kernel tests in the __second commit__.
__Third commit__ unifies short ternary operator, e.g. `$foo ?: new Foo()`. __Forth commit__ unifies missing parentheses, e.g. `new Foo()`.
Commits
-------
077a089 unify missing parentheses
2888594 unify short ternary operator
2a9daff [HttpKernel] better written kernel tests
111ac18 unify constructor initialization style throughout symfony
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
-------
51223c0 added upgrade instructions
50e6259 adjusted tests
98f3ca8 [Routing] removed tree structure from RouteCollection
Discussion
----------
[Routing] removed tree structure from RouteCollection
BC break: yes (see below)
Deprecations: RouteCollection::getParent(); RouteCollection::getRoot()
tests pass: yes
The reason for this is so quite simple. The RouteCollection has been designed as a tree structure, but it cannot at all be used as one. There is no getter for a sub-collection at all. So you cannot access a sub-collection after you added it to the tree with `addCollection(new RouteCollection())`. In contrast to the form component, e.g. `$form->get('child')->get('grandchild')`.
So you can see the RouteCollection cannot be used as a tree and it should not, as the same can be achieved with a flat array!
Using a flat array removes all the need for recursive traversal and makes the code much faster, much lighter, less memory (big problem in CMS with many routes) and less error-prone.
BC break: there is only a BC break if somebody used the PHP API for defining RouteCollection and also added a Route to a collection after it has been added to another collection.
So
```
$rootCollection = new RouteCollection();
$subCollection = new RouteCollection();
$rootCollection->addCollection($subCollection);
$subCollection->add('foo', new Route('/foo'));
```
must be updated to the following (otherwise the 'foo' Route is not imported to the rootCollection)
```
$rootCollection = new RouteCollection();
$subCollection = new RouteCollection();
$subCollection->add('foo', new Route('/foo'));
$rootCollection->addCollection($subCollection);
```
Also one must call addCollection from the bottom to the top. So the correct sequence is the following (and not the reverse)
```
$childCollection->->addCollection($grandchildCollection);
$rootCollection->addCollection($childCollection);
```
Remeber, this is only needed when using PHP for defining routes and calling methods in a special order. There is no change required when using XML or YAML for definitions. Also, I'm pretty sure that neither the CMF, nor Drupal routing, nor Silex is relying on the tree stuff. So they should also still work.
cc @fabpot @crell @dbu
One more thing: RouteCollection wasn't an appropriate name for a tree anyway as a collection of routes (that it now is) is definitely not a tree.
Yet another point: The XML declaration of routes uses the `<import>` element, which is excatly what the new implementation of addCollection without the need of a tree does. So this is now also more analogous.
---------------------------------------------------------------------------
by Koc at 2012-11-26T17:34:15Z
What benefit of this?
---------------------------------------------------------------------------
by Tobion at 2012-11-26T17:56:53Z
@Koc Why did you not simply wait for the description? ^^
---------------------------------------------------------------------------
by dbu at 2012-11-26T18:33:09Z
i love PR that remove more code than they add whithout removing functionality.
---------------------------------------------------------------------------
by Crell at 2012-11-26T18:49:52Z
There's an issue somewhere in Drupal where we're trying to use addCollection() as a shorthand for iterating over one collection and calling add() on the other for each item. We can't do that, however, because the subcollections are not flattened properly when reading back and our current dumper can't cope with that. So this change would not harm Drupal at all, and would mean I don't have fix a bug in our dumper. :-) I cannot speak for any other projects, of course.
---------------------------------------------------------------------------
by Tobion at 2012-11-27T19:06:34Z
Ok, this is ready.
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.
This allows as to define default like this
foo:
pattern: /{_locale}/login
defaults:
_controller: my_login_controller:loginAction
_locale: %session.default_locale%
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.
The _scheme requirement can be used to force routes to always match one given scheme
and to always be generated with the given scheme.
So, if _scheme is set to https, URL generation will force an absolute URL if the
current scheme is http. And if you request the URL with http, you will be redirected
to the https URL.
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.
Before I explain the changes, let's talk about the current state.
Before this patch, the registerBundleDirs() method returned an ordered (for
resource overloading) list of namespace prefixes and the path to their
location. Here are some problems with this approach:
* The paths set by this method and the paths configured for the autoloader
can be disconnected (leading to unexpected behaviors);
* A bundle outside these paths worked, but unexpected behavior can occur;
* Choosing a bundle namespace was limited to the registered namespace
prefixes, and their number should stay low enough (for performance reasons)
-- moreover the current Bundle\ and Application\ top namespaces does not
respect the standard rules for namespaces (first segment should be the
vendor name);
* Developers must understand the concept of "namespace prefixes" to
understand the overloading mechanism, which is one more thing to learn,
which is Symfony specific;
* Each time you want to get a resource that can be overloaded (a template for
instance), Symfony would have tried all namespace prefixes one after the
other until if finds a matching file. But that can be computed in advance
to reduce the overhead.
Another topic which was not really well addressed is how you can reference a
file/resource from a bundle (and take into account the possibility of
overloading). For instance, in the routing, you can import a file from a
bundle like this:
<import resource="FrameworkBundle/Resources/config/internal.xml" />
Again, this works only because we have a limited number of possible namespace
prefixes.
This patch addresses these problems and some more.
First, the registerBundleDirs() method has been removed. It means that you are
now free to use any namespace for your bundles. No need to have specific
prefixes anymore. You are also free to store them anywhere, in as many
directories as you want. You just need to be sure that they are autoloaded
correctly.
The bundle "name" is now always the short name of the bundle class (like
FrameworkBundle or SensioCasBundle). As the best practice is to prefix the
bundle name with the vendor name, it's up to the vendor to ensure that each
bundle name is unique. I insist that a bundle name must be unique. This was
the opposite before as two bundles with the same name was how Symfony2 found
inheritance.
A new getParent() method has been added to BundleInterface. It returns the
bundle name that the bundle overrides (this is optional of course). That way,
there is no ordering problem anymore as the inheritance tree is explicitely
defined by the bundle themselves.
So, with this system, we can easily have an inheritance tree like the
following:
FooBundle < MyFooBundle < MyCustomFooBundle
MyCustomFooBundle returns MyFooBundle for the getParent() method, and
MyFooBundle returns FooBundle.
If two bundles override the same bundle, an exception is thrown.
Based on the bundle name, you can now reference any resource with this
notation:
@FooBundle/Resources/config/routing.xml
@FooBundle/Controller/FooController.php
This notation is the input of the Kernel::locateResource() method, which
returns the location of the file (and of course it takes into account
overloading).
So, in the routing, you can now use the following:
<import resource="@FrameworkBundle/Resources/config/internal.xml" />
The template loading mechanism also use this method under the hood.
As a bonus, all the code that converts from internal notations to file names
(controller names: ControllerNameParser, template names: TemplateNameParser,
resource paths, ...) is now contained in several well-defined classes. The
same goes for the code that look for templates (TemplateLocator), routing
files (FileLocator), ...
As a side note, it is really easy to also support multiple-inheritance for a
bundle (for instance if a bundle returns an array of bundle names it extends).
However, this is not implemented in this patch as I'm not sure we want to
support that.
How to upgrade:
* Each bundle must now implement two new mandatory methods: getPath() and
getNamespace(), and optionally the getParent() method if the bundle extends
another one. Here is a common implementation for these methods:
/**
* {@inheritdoc}
*/
public function getParent()
{
return 'MyFrameworkBundle';
}
/**
* {@inheritdoc}
*/
public function getNamespace()
{
return __NAMESPACE__;
}
/**
* {@inheritdoc}
*/
public function getPath()
{
return strtr(__DIR__, '\\', '/');
}
* The registerBundleDirs() can be removed from your Kernel class;
* If your code relies on getBundleDirs() or the kernel.bundle_dirs parameter,
it should be upgraded to use the new interface (see Doctrine commands for
many example of such a change);
* When referencing a bundle, you must now always use its name (no more \ or /
in bundle names) -- this transition was already done for most things
before, and now applies to the routing as well;
* Imports in routing files must be changed:
Before: <import resource="Sensio/CasBundle/Resources/config/internal.xml" />
After: <import resource="@SensioCasBundle/Resources/config/internal.xml" />
Currently, ambiguities only arise for PHP files, as PhpFileLoader and AnnotationFileLoader would both claim support. Future conflicts may occur if the XML, YAML, or PHP loaders were to receive Directory and Glob loaders (as annotations have).
Since the "type" parameter is optional, loader resolution will default to awarding resolution to the first loader to claim support. A previous hack in PhpFileLoader to avoid an AnnotationFileLoader conflict was removed, so that should be the only lost backwards compatibility with this patch. Unit tests were also created for the various loader classes, although only the supports() method is being tested.
This implementation was proposed on the symfony-dev mailing list in response to Fabien's RFC for custom loader notation: http://groups.google.com/group/symfony-devs/browse_thread/thread/3104c1a9e45799d2/20fbe393c1afe088
* removed the Kernel::registerRoutes() method
* added a router entry in <web:config> (replaces the registerRoutes() method)
<web:config>
<web:router resource="%kernel.root_dir%/config/routing.xml" />
</web:config>
* refactored routing configuration in its own routing.xml file (leverages the new routing component API),
which is loaded only if <web:router> is defined in the configuration