This PR was squashed before being merged into the master branch (closes#5904).
Commits
-------
84adcb1 [2.2][Routing] Added support for default attributes with default values of method params
Discussion
----------
[2.2][Routing] Added support for default attributes with default values of method params
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
With this patch, you can configure your default values likes this:
``` php
/**
* @Route("/hi/{name}", name="hi")
*/
public function hiAction($name = "Bob")
{
return new Response($name);
}
```
---------------------------------------------------------------------------
by Tobion at 2012-11-03T23:15:32Z
I'm unsure. How does one know if that param defines a default value or a requirement? It's too vague.
---------------------------------------------------------------------------
by lyrixx at 2012-11-03T23:35:27Z
It's only a default value, not a requirement.
It's just a shortcut to avoid `defaults={"name"="bob"}`
---------------------------------------------------------------------------
by Tobion at 2012-11-03T23:43:51Z
Yes, but its not clear. It could also be a shortcut to `requirements={"name"="bob"}`, which has totally different meaning. So it's not self-explanatory.
-1 for me.
---------------------------------------------------------------------------
by lyrixx at 2012-11-03T23:48:21Z
it is the default php behavior. It's a default value for a variable...
---------------------------------------------------------------------------
by stof at 2012-11-04T00:22:58Z
@Tobion using the default value of the method to set a requirement does not make any sense. I don't see why someone would expect this behavior
---------------------------------------------------------------------------
by fabpot at 2012-11-06T10:12:05Z
@lyrixx Can you add some unit tests?
---------------------------------------------------------------------------
by Tobion at 2012-11-06T10:28:42Z
Oh I misunderstood the PR. I thought this makes the `name` param default to `hi`. `@Route("/hi/{name}", name="hi")`. But it's just the name of the route. Your example was easy to misinterpret as you used `name` everywhere.
---------------------------------------------------------------------------
by fabpot at 2012-11-10T08:33:13Z
@lyrixx Can you finish this PR?
---------------------------------------------------------------------------
by lyrixx at 2012-11-10T13:16:34Z
@fabpot Yes i will as soon as possible.
---------------------------------------------------------------------------
by lyrixx at 2012-11-10T18:34:07Z
I rebase and amend my commit. (I changed doc in commit message to be less confusing)
I will try to add tests.
But for now, `AnnotationClassLoader::load` is not really tested, and `AnnotationClassLoader::addRoute` is absolutely not tested. So I think I should add tests for these methods ? And then add tests for my patch.
I will try tomorrow.
---------------------------------------------------------------------------
by lyrixx at 2012-11-11T18:23:41Z
@fabpot I added new tests. I tried to made very atomic commits.
This PR was merged into the master branch.
Commits
-------
c7a8f7a [Routing] fixed possible parameters conflict in apache url matcher
Discussion
----------
[Routing] fixed possible parameters conflict in apache url matcher
Bug fix: yes
Feature addition: no
Backwards compatibility break: no (as long as rewrite rules are generated after upgrading)
Symfony2 tests pass: yes
- This fixes a conflict in route parameters:
The rewrite rules currently pass route informations through environment variables:
`_ROUTING_DEFAULT_x`: passes the default value of parameter x
`_ROUTING__allow_x`: passes the information that method x was allowed for this route
`_ROUTING_x`: passes the value of parameter x
The problem is that naming a route parameter `DEFAULT_*` or `_allow_*` would not behave as expected.
I fixed this by namespacing all environment variables; e.g. parameters are in `_ROUTING_param_*`, defaults in `_ROUTING_default_*`, etc.
- The PR fixes a second issue: sometimes the variables are prefixed with multiple REDIRECT_. This PR handles this case by ignoring them all.
- This also improves performance a little:
Matching a route with two parameters and two default parameters 100K times: (`$_SERVER` was copied from a real request, so with many non `_ROUTING_` variables)
master: 6.6s
this branch: 4.7s
---------------------------------------------------------------------------
by fabpot at 2012-10-27T13:37:24Z
Any news on this PR? Is it mergeable?
---------------------------------------------------------------------------
by arnaud-lb at 2012-10-27T14:50:08Z
There is an issue with default parameter values, I can't find how to fix that in a simple way. Before this PR, default values are never used (if a parameter is an optional not present in the url, the parameter's value is the empty string); after this PR, when a parameter is present and empty (e.g. a requirement like `.*`), its value is set to its default value.
---------------------------------------------------------------------------
by Tobion at 2012-10-29T01:36:08Z
The problem is, it's not consistent with the default php matcher. So one cannot safely exchange it with the apache matcher because it behaves differently under some (special) circumstances.
---------------------------------------------------------------------------
by fabpot at 2012-11-05T08:05:54Z
We need to move forward as I want to merge the hostname support in the routing ASAP to have plenty of time for feedback before the 2.2 release.
Does it sound reasonable to merge this PR as is an open a ticket about the remaining issue (which should not occur that often anyways)?
---------------------------------------------------------------------------
by arnaud-lb at 2012-11-05T09:22:02Z
@fabpot it sounds reasonable to me. Also, I've the hostname support branch is currently rebased so that it can be merged without this one.
---------------------------------------------------------------------------
by Tobion at 2012-11-11T21:50:20Z
Btw, does the ApacheMatcherDumper handle the _scheme requirement? It doesn't look like it. This would be another bug.
Anyway, we can probably merge this PR and open new issues for the remaining bugs.
This PR was merged into the master branch.
Commits
-------
e54d749 [Routing] Simplified php matcher dumper (and optimized generated matcher)
Discussion
----------
[Routing] Simplified php matcher dumper (and optimized generated matcher)
Bug fix: no
Feature addition: no
Related: #3378
Backwards compatibility break: no
Symfony2 tests pass: yes
This simplifies the php matcher dumper by allowing the dumper to re-organize routes in the dumper's own structure.
As a result, dumping is made a little simpler. This is also helps much for my hostname-based routes PR #3378.
Reorganizing routes also allows to find more optimization opportunities:
Currently the dumper wraps some collections of routes in a `if (0 === strpos($pathinfo, '/someprefix')` if the collection has user-defined prefix, and if it contains more than one direct child Route. This can miss many optimization opportunities.
The PR changes this by building a prefix tree of routes based on the static prefix extracted from routes' patterns. Then every leave having a prefix and more than one child (route or collection) will be wrapped in a `if` statement.
Example:
```
// No explicit prefix is specified
@Route("/cafe")
@Route("/cacao")
@Route("/coca")
```
is compiled like this:
```
if (url starts with /c) {
if (url starts with /ca) {
// test route "/cafe"
// test route "/cacao"
}
// test route "/coca"
}
```
Some tests have many white space changes, much more easier to review [here](https://github.com/symfony/symfony/pull/5734/files?w=1)
---------------------------------------------------------------------------
by Tobion at 2012-10-13T02:27:54Z
I'm not sure if adding these specific classes just for dumping is the best implementation because they duplicate some logic and this optimization should also work out-of-the-box with the standard RouteCollection etc.
What I have in mind is a new method in RouteCollection like `RouteCollection::optimizeTree` that returns a new RouteCollection with the Routes that includes these optimization you do here. So there would probably be no need for the new classes.
It think it requires some changes in RouteCollection like the handling of prefix that must start with a slash currently, which is too restrictive. But it should be possible.
---------------------------------------------------------------------------
by arnaud-lb at 2012-10-13T12:52:32Z
@Tobion
> I'm not sure if adding these specific classes just for dumping is the best implementation because they duplicate some logic and this optimization should also work out-of-the-box with the standard RouteCollection etc.
I think RouteCollection and DumperCollection do not share the same concerns; and RouteCollection does things that don't allow to reorganize routes freely. For instance when adding a collection to a RouteCollection this changes all the child routes' prefix, requirements, options, etc. When setting a collection's prefix, this prepends the prefix to every child route's pattern, etc.
---------------------------------------------------------------------------
by arnaud-lb at 2012-10-15T08:50:23Z
squashed the CS commits
---------------------------------------------------------------------------
by arnaud-lb at 2012-10-15T13:50:16Z
@fabpot @Tobion this PR is ready to be merged if everyone agrees
---------------------------------------------------------------------------
by Tobion at 2012-10-16T18:10:36Z
When the above is fixed, I think it's good to be merged.
---------------------------------------------------------------------------
by arnaud-lb at 2012-10-17T08:40:20Z
Fixed; thanks @Tobion @stof for your reviews
---------------------------------------------------------------------------
by Tobion at 2012-10-19T03:30:10Z
@arnaud-lb could you please test whether your PR fixes#5780 as a side-effect?
I can image that it's fixed because you use `$route->compile()->getStaticPrefix();` for prefix optimization.
If it's fixed please add a test case. If not, that's fine, and we need to fix it in another PR.
* 2.1: (28 commits)
Delete use of CreationExeption
[Form] Fixed error message in PropertyPath to not advice to use a non-existing feature
[Form] Fixed creation of multiple money fields with different currencies
[Form] Fixed setting the "data" option to an object in "choice" and "entity" type
Fixed Serbian plural translations.
Fixed IPv6 Check in RequestMatcher
Fix typo
change what I think is a typo
[Console] Fix error when mode is not in PATH
[WebProfilerBundle] fixed macro usage (to be forward compatible with Twig 2.x)
Change monolog require-dev to use the branch alias instead of dev-master
[FrameworkBundle] partially reverted previous merge
[2.1] Added missing error return codes in commands
Made the router lazy when setting the context
[WebProfilerBundle] fixed typos
Fix incorrect variable in FileProfilerStorage
UnitTest fix
UnitTest fix
added a unit test
fixed#5384
...
This PR was merged into the master branch.
Commits
-------
e22823b [Routing] context params should have higher priority than defaults
16c1b01 [Routing] fixed 4 bugs in the UrlGenerator
Discussion
----------
[Routing] UrlGenerator: fixed missing query param and some ignored requirements
reopened version of #5181 (cherry-picked)
On top of that I fixed#5437 in my code and added test case.
---------------------------------------------------------------------------
by Tobion at 2012-10-03T18:41:45Z
@fabpot ping
---------------------------------------------------------------------------
by fabpot at 2012-10-03T18:43:43Z
IIUC, #5437 is a regression in 2.1 and should be done in 2.1, no?
---------------------------------------------------------------------------
by Tobion at 2012-10-03T18:46:42Z
It's not in 2.1 anymore as you reverted the PR. #5437 is not valid currently and can be closed.
So this can either be merged in master or 2.1 whatever you prefer.
My benchmarks showed a performance improvement of 20% when matching routes that make use of possesive quantifiers because it prevents backtracking when it's not needed
Commits
-------
02516de [Routing] fix variable with a requirement of '0'
1f5b793 [Routing] fix setting empty requirement in Route
Discussion
----------
[Routing] fix setting empty requirement
First commit: A requirement of "^$" was overlooked and wasn't recognized as empty after stripping it in Route.
Second commit: Fixes a requirement of '0' that was ignored by the Compiler.
Commits
-------
be28e56 [Routing] disallow numeric named variables in pattern
Discussion
----------
[Routing] compile check for numeric named variables in pattern
Because PHP raises an error for such subpatterns in PCRE and thus would break matching, e.g. this is not allowed as regex `(?<123>.+)`.
So add a compile time check for a non-working pattern like '/{123}'.
---------------------------------------------------------------------------
by sstok at 2012-09-06T08:31:42Z
Strangely enough Regex buddy gives no warning or error with the pattern.
Is the name all numeric invalid or just the beginning?
1e4 and 0xFF would be perfectly valid but returns true with is_nummeric()
---------------------------------------------------------------------------
by Tobion at 2012-09-06T08:59:07Z
Any numeric is not valid. I guess this limitation is unique to PHP's binding to PCRE.
I think it's because the returned matches array of of preg_match contains both the subpattern as integer index and as named variable. So having a numeric named variable would conflict as `array['1'] === array[1]`.
Commits
-------
7c5cfeb [Routing] added test why #5238 is not that easy
Discussion
----------
[Routing] added test why #5238 is not that easy
This just adds a test that wasn't covered yet and shows why #5238 is not that easy as I thought at first.
Commits
-------
0706d18 [Routing] fixed 4 bugs in the UrlGenerator
Discussion
----------
[Routing] UrlGenerator: fixed missing query param and some ignored requirements
This was pretty hard to figure out. I could fix 4 bugs and refactor the code to safe 2 variables and several assignments. Sorry for doing this in one commit, but they were highly interdependent.
See the added tests for what was fixed. The most obvious bug was that a query param was ignored if it had by accident the same name as a default param (but wasn't used in the path).
In 3 cases it generated the wrong URL that wouldn't match this route. The generator wrongly ignored either the requirements or the passed parameter. I had to adjust one test that was asserting something wrong (see comments).
---------------------------------------------------------------------------
by Tobion at 2012-08-13T14:22:35Z
ping @fabpot
---------------------------------------------------------------------------
by Tobion at 2012-08-29T17:53:07Z
@fabpot I think it's important to merge this before 2.1 final.
* 2.0:
updated VERSION for 2.0.17
updated CHANGELOG for 2.0.17
updated vendors for 2.0.17
fixed XML decoding attack vector through external entities
prevents injection of malicious doc types
disabled network access when loading XML documents
refined previous commit
prevents injection of malicious doc types
standardized the way we handle XML errors
Redirects are now absolute
Conflicts:
CHANGELOG-2.0.md
src/Symfony/Component/DependencyInjection/Loader/XmlFileLoader.php
src/Symfony/Component/DomCrawler/Crawler.php
src/Symfony/Component/HttpKernel/Kernel.php
tests/Symfony/Tests/Component/DependencyInjection/Loader/XmlFileLoaderTest.php
tests/Symfony/Tests/Component/Routing/Loader/XmlFileLoaderTest.php
tests/Symfony/Tests/Component/Serializer/Encoder/XmlEncoderTest.php
tests/Symfony/Tests/Component/Translation/Loader/XliffFileLoaderTest.php
tests/Symfony/Tests/Component/Validator/Mapping/Loader/XmlFileLoaderTest.php
vendors.php
Commits
-------
3466896 [Routing] fix encoding of static static, so UrlGenerator produces valid URLs
Discussion
----------
[Routing] fix encoding of static text
Fixes#4166
As requested by Fabien, I split #4205 into multiple PRs.
---------------------------------------------------------------------------
by stof at 2012-06-09T12:49:32Z
github tells me this PR cannot be merged automatically. Could you rebase it ?
---------------------------------------------------------------------------
by Tobion at 2012-06-09T13:12:55Z
Done
---------------------------------------------------------------------------
by travisbot at 2012-06-09T13:18:18Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1576266) (merged 3466896a into 15b5aa4f).
Commits
-------
49e9957 added test to ensure matching is eager
Discussion
----------
[Routing] added test to ensure matching is eager
This just adds a passing test that wasn't covered yet, so we don't break this scenario in the future.
---------------------------------------------------------------------------
by travisbot at 2012-06-13T01:04:09Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1605738) (merged 49e99572 into 37550d23).
Commits
-------
a196ca0 [Routing] Compiler: remove lazy quantifiers with no effect
8232aa1 [Routing] Compiler: fix in the computing of the segment separators
Discussion
----------
[Routing] Fix the matching process
This PR is based on the PR #3678, #4139.
[](http://travis-ci.org/vicb/symfony)
**The spec**
A pattern is composed of both text and variable segments: `/{variable}-test/{other_variable}`.
A variable segment will match anything until a separator is encountered. The separator is the character following the variable segment when available or preceding the variable otherwise (i.e. at the end of the pattern).
That is:
* the separator is `-` for the `variable`,
* the separator is `/` for the `other_variable`.
*Note: This default matching behavior can be overridden if a requirement is specified for a variable)*
**Fixes**
* The current behavior is to consider booth the preceding and following characters as separators (considering availability),
* The "preceding" separator of the first variable is always set to `/` whatever the preceding character is (due to `$pos = 0` for the first iteration).
**Todo**
Update the doc once this is merged
Commits
-------
c195957 [Components] Tests/Autoloading fixes
Discussion
----------
Fix components
See #4141
----
This PR:
* configures each component to use composer to manage "dev" dependencies instead of env variables;
* adds phpunit configuration file on Filesystem component;
* fixes READMEs.
It's mergeable without any problems, but I would recommend to wait a fix in Composer in order to use `self.version` in `require`/`require-dev` sections.
Note: I kept `suggest` sections because it makes sense but this PR doesn't aim to provide useful explanations for each entry. It could be another PR, not that one.
---------------------------------------------------------------------------
by willdurand at 2012-04-30T20:43:13Z
@fabpot I reviewed each component, one by one. Now `phpunit` always works, even if tests are skipped. A simple `composer install --dev` allows to run the complete test suite. Each commit is well separated from the others. I guess, everything is ok now.
---------------------------------------------------------------------------
by Tobion at 2012-04-30T20:47:00Z
Please squash, as it makes no sense to have the same commit for each component.
---------------------------------------------------------------------------
by fabpot at 2012-05-01T14:26:11Z
Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by willdurand at 2012-05-01T14:29:38Z
done
---------------------------------------------------------------------------
by fabpot at 2012-05-01T15:48:25Z
It does not seem that the commits are squashed.
---------------------------------------------------------------------------
by willdurand at 2012-05-01T15:54:08Z
done
* Switched to Composer to manage "dev" dependencies
* Fixed READMEs
* Excluded vendor in phpunit.xml.dist files
* Fixed message in bootstrap.php files
* Added autoloader for the component itself
Commits
-------
56c1e31 performance improvement in PhpMatcherDumper
Discussion
----------
performance improvement in PhpMatcherDumper
Tests pass: yes
The code generation uses a string internally instead of an array. The array wasn't used for random access anyway.
I also removed 4 unneeded iterations this way (when imploding, when merging and twice when applying the extra indention). A `preg_replace` could also be saved under certain circumstances by moving it.
And there was a small code errror in line 139.
