Commits
-------
b961ee3 [HttpFoundation] Fixed the tests
Discussion
----------
[HttpFoundation] Fixed the tests
b8a2f8c646 reverted the use of the username
and password in the getSchemeAndHost method but forgot to revert the
corresponding tests.
Commits
-------
8ab3054 added dirs generated by build-data.php in locale component to .gitignore
Discussion
----------
added dirs generated by build-data.php in locale component to .gitignore
This is to complete the PR #5411.
Paging @eriksencosta.
---------------------------------------------------------------------------
by eriksencosta at 2012-09-25T14:54:06Z
For me it's ok!
Batman?
---------------------------------------------------------------------------
by shieldo at 2012-09-25T14:55:38Z
Kapow! Thanks for checking it over!
---------------------------------------------------------------------------
by shieldo at 2012-09-25T15:41:05Z
As @stof pointed out, git does read .gitignore files in sub-paths. So I've modified the commit so the change is in the Locale component only.
Commits
-------
530bd22 fixed issue #5596 (Broken DOM with the profiler's toolbar set in position top)
Discussion
----------
fixed issue #5596 (Broken DOM with the profiler's toolbar set in position top)
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5596
Todo: -
License of the code: MIT
Documentation PR: -
Whatever the toolbar position, the html code associated to it may be placed at the end of the page (and this will be better from a webperf point of view).
---------------------------------------------------------------------------
by stof at 2012-09-25T17:47:53Z
The spacer div will not be in the right place when using ``position: top`` as it will be at the end of the body.
---------------------------------------------------------------------------
by pborreli at 2012-09-25T17:53:03Z
@stof what is the spacer div ? i guess all the profiler is in absolute so i guess it should work (and I'm sure @xavierlacot already tested it :))
---------------------------------------------------------------------------
by pborreli at 2012-09-25T17:55:55Z
@xavierlacot so maybe we should refactor
```
$pos = $posrFunction($content, '</body>');
$content = $substrFunction($content, 0, $pos).$toolbar.$substrFunction($content, $pos);
```
with something like
```
$content = str_replace('</body>', $toolbar.'</body>', $content);
```
What do you think ?
---------------------------------------------------------------------------
by stof at 2012-09-25T17:58:35Z
@pborreli The toolbar is in position fixed. But to avoid hiding some of the content of your page, another div is added on with a margin, to force keeping some space after the content for the toolbar. With this change, the toolbar HTML is always at the end, so the 40px space is always added at the bottom of the page even if the toolbar is added at the top.
---------------------------------------------------------------------------
by pborreli at 2012-09-25T18:03:08Z
@stof maybe we should just fix the body/html margin-top in that case no ? or find a better solution, anyway I think the actual way to do it is bad, `<body>` and `</body>` are not even mandatory in html5, IMHO i would just put it at the end of file without any check, then fix it with some css and/or js
---------------------------------------------------------------------------
by stof at 2012-09-25T18:06:58Z
@pborreli Putting it at the end after the closing ``<html>`` tag would make the page invalid for people defining the markup fully. It is a bad idea.
And anyway, detecting the body tag is still important, to avoid injecting the toolbar in partial page content (be it ESI requests or parts loaded through AJAX).
Oh, and ``$content = str_replace('</body>', $toolbar.'</body>', $content);`` would not fix#5596 but make it worse: it would also inject the toolbar in the head even when being placed at the bottom (keeping it at the bottom too).
---------------------------------------------------------------------------
by pborreli at 2012-09-25T18:18:46Z
@stof for detecting ajax you already have `if ($request->isXmlHttpRequest()) {` called few lines before,
the proposal for `$content = str_replace('</body>', $toolbar.'</body>', $content);` was only a refactoring for the above PR
---------------------------------------------------------------------------
by stof at 2012-09-25T18:26:34Z
@pborreli ESI requests are not AJAX requests. So simply appending at the end would still break them.
And your code is *not* a refactoring. Your ``str_replace`` will replace **all** occurences of ``</body>``, not just the last one. See the related issue to understand why it makes a difference
---------------------------------------------------------------------------
by pborreli at 2012-09-25T18:38:11Z
ok I'm all wrong.
---------------------------------------------------------------------------
by xavierlacot at 2012-09-25T18:51:42Z
@stof, please review the last commit, which injects the wdt container at the top of the page in javascript, using the browser's DOM capacities. This fixes the spacer problem that you noticed.
---------------------------------------------------------------------------
by stof at 2012-09-25T18:55:51Z
Well, you are now breaking things when the spacer should be at the bottom as you are always putting the spacer at the top.
---------------------------------------------------------------------------
by stloyd at 2012-09-25T19:06:14Z
@xavierlacot Pass `position` variable to template and change:
```diff
- document.body.insertBefore(sfwdt, document.body.firstChild);
+ {% if position == 'bottom' -%}
+ document.body.appendChild(sfwdt);
+ {%- else -%}
+ document.body.insertBefore(sfwdt, document.body.firstChild);
+ {%- endif %}
---------------------------------------------------------------------------
by stof at 2012-09-25T20:18:31Z
@xavierlacot could you squash your commits ?
---------------------------------------------------------------------------
by xavierlacot at 2012-09-25T21:32:47Z
@stof done. Thanks for the review :-)
Commits
-------
ef288a2 [Form] Fixed the testsuite for PHPUnit 3.6 as travis still uses it
Discussion
----------
[Form] Fixed the testsuite for PHPUnit 3.6
Travis is still using it so this avoids making all build fail just because of it.
Commits
-------
c869a65 [Console] Fixed return value for Command::run
Discussion
----------
[2.1][Console] Fixed return value for Command::run
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
API says that Command::run returns integer. This is also necessary if I want to run nested commands.
Commits
-------
cc46780 [Console] Fix some input tests
Discussion
----------
[Console] Fix some input tests
New PR for console input tests, was previously on the master branch : https://github.com/symfony/symfony/pull/5567
* 2.1:
fixed stringification of array objects in RequestDataCollector (closes#5295)
[HttpFoundation] removed the username and password from generated URL as generated by the Request class (closes#5555)
[Console] fixed default argument display (closes#5563)
Fixing config normalisation example in docblock
* 2.0:
fixed stringification of array objects in RequestDataCollector (closes#5295)
Fixing config normalisation example in docblock
Conflicts:
src/Symfony/Bridge/Doctrine/DataCollector/DoctrineDataCollector.php
src/Symfony/Component/HttpKernel/DataCollector/RequestDataCollector.php
Quoted from the ticket it solves for future reference:
"I've been having issues with using htdigest auth (requirement for me to
work with) after upgrading to 2.1. Each time a resource is loaded, a
prompt is given for the HTTP Auth username and password, and Chrome does
not automatically respond to these 401 responses with the credentials it
already has. I've traced the issue to being caused by the HttpFoundation
Component, specifically Request.php.
The request class adds the PHP_AUTH_USER/PHP_AUTH_PW parameters to the
request URI (changes http://www.mysite.com requests to
http://user:pw@www.mysite.com) in getSchemeAndHttpHost(). This behaviour
is not specified in the HTTP RFC, and is incompatible with Chrome as of
Chrome 19, IE (as of IE 9) and has special behaviour in Firefox (prompts
the user to confirm they know they're logging into the site, which is an
ambiguous behaviour at best, but at least it's something if they're
going to support it for now).
This functionality was added about to HttpFoundation about a year ago,
but it really should be removed and standard protocol practices should
be followed. This practice makes it possible for cross-site tracking and
other malicious behaviours to be performed by hiding information in the
authorization headers, which explains why most browsers no longer
support or take exception with it.
The offending line is specifically this. Replacing it with return
$this->getScheme().'://'.$this->getHttpHost(); seems to solve the
problem."
Commits
-------
6bafe5a moved some code to the component
Discussion
----------
moved some code to the component
This simply moves some code from a command to a dedicated class to make it more reusable.
I wasn't able to run tests because composer failed to install dependencies. Let's see if travis can do better.
* 2.1:
bumped Symfony version to 2.1.3-DEV
updated VERSION for 2.1.2
updated CHANGELOG for 2.1.2
Fixed FlashBagInterface phpdoc, clarified UPGRADE docs
composer is available in travis workers
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
Commits
-------
589a8b3 composer is available in travis workers
Discussion
----------
composer is available in travis workers
---------------------------------------------------------------------------
by bamarni at 2012-09-19T09:07:30Z
reverted
---------------------------------------------------------------------------
by stof at 2012-09-19T09:59:21Z
btw, in the 2.1 branch, the ``COMPOSER_ROOT_VERSION`` varaible should be set to ``2.1.x-dev``
---------------------------------------------------------------------------
by bamarni at 2012-09-19T14:44:48Z
@stof: ok, btw I don't understand the issue, deps are solvable without this, is it a workaround to make this package known as 2.1 even though it's not guessable with the branch name (eg. when using a feature branch for a PR)? I thought this was handled by the branch-alias.
---------------------------------------------------------------------------
by stof at 2012-09-19T15:54:05Z
@bamarni It is solvable in some cases but not in all of them. Sometimes, when being in a detached head (which is the case when Travis builds PRs), the guessing of the composer root version does not work, and so symfony dev deps depending on some symfony components (Doctrine) will fail because the guessed version would not match ``2.*`` (which is the Doctrine requirement for the components).
branch aliases have nothing to do with the guessing of the version for the root package.
---------------------------------------------------------------------------
by stof at 2012-09-19T15:55:25Z
btw, the only cases where COMPOSER_ROOT_VERSION could be needed is when some of your dependencies have a requirement on your root package. Otherwise, the root version is never needed by composer to resolve deps
---------------------------------------------------------------------------
by bamarni at 2012-09-19T16:52:52Z
@stof: in detached head indeed the version can't be guessed with git, so this change avoid potential issues with reciprocal dependencies (I guess it can also be solved by specifying a "version" in composer.json).
But I still don't get why you say branch aliases have nothing to do with the root package version, isn't the purpose of a "2.1-dev" branch-alias to be matched when specifying this package as a dependency with 2.1.*, no matter the branch name or if git is in detached head?
---------------------------------------------------------------------------
by stof at 2012-09-19T18:59:13Z
@bamarni a **branch** alias is about the aliasing the version of a branch. Look at how it is written. It tells composer that for Symfony, the ``dev-master`` version (so the master branch) should receive an alias ``2.2.x-dev``.
This alias will never help you if your root version cannot be guessed as being ``dev-master``.
---------------------------------------------------------------------------
by bamarni at 2012-09-19T20:43:19Z
ahh... in my mind branch alias was only an alias for the current branch, I forgot that it was a 'branch => alias' map, indeed in that case it can't help at all.
thx for the explanations ;)
Commits
-------
6cbeff0 use ->find instead of ->get in the help command to allow command aliases to be used (e.g. "./app/console help do:sc:ge")
Discussion
----------
use ->find instead of ->get in the help command to allow command aliases...
... to be used (e.g. "./app/console help do:sc:ge")
Commits
-------
bb0e4c3 Fixed FlashBagInterface phpdoc, clarified UPGRADE docs
Discussion
----------
Fixed FlashBagInterface phpdoc, clarified upgrade doc
The fact that multiple flash messages are now stored/retrieved per type was an additional BC break that I missed when I first went through the 2.1 update doc, and it didn't help that the phpdoc was outdated.
These changes just clarify things a little.
---------------------------------------------------------------------------
by drak at 2012-09-20T07:45:52Z
+1
Commits
-------
71db836 Better config validation handling for numerical values: * New node type Integer and Float * New expressions: min() and max()
Discussion
----------
[2.2] [Config] Better handling for numerical values:
* New node type Integer and Float
* New expressions: ifLessThan(), ifGreaterThan(), ifInRange(), ifNotInRange()
---------------------------------------------------------------------------
by fabpot at 2012-07-03T08:50:22Z
As I said on PR #4713, adding more method clutters the API without any big benefits. I'm -1 on the PR.
---------------------------------------------------------------------------
by jeanmonod at 2012-07-03T08:54:36Z
I have been discuss it with @schmittjoh at the sflive, he was thinking it could be a good addition.
IMHO I think that if we want to encourage the usage of bundle configuration validation, we should make it as easy as possible to use...
---------------------------------------------------------------------------
by jeanmonod at 2012-07-03T08:59:42Z
A real life example:
->scalarNode('max_nb_items')
->validate()
->ifTrue(function($v){
return !is_int($v) || (is_int($v) && $v<1);
})
->thenInvalid('Must be a positive integer')
->end()
->end()
could be replaced by
->integerNode('max_nb_items')
->validate()
->ifLessThan(1);
->thenInvalid('Must be a positive integer')
->end()
->end()
---------------------------------------------------------------------------
by gnutix at 2012-07-03T09:03:06Z
I agree with @jeanmonod on this matter, the bundle configuration validation is already kind of a hassle to understand (and read), so it would be a good addition IMHO.
---------------------------------------------------------------------------
by fabpot at 2012-07-03T10:54:32Z
@schmittjoh What's your point of view?
---------------------------------------------------------------------------
by schmittjoh at 2012-07-03T14:10:37Z
The integer and float nodes are valuable additions imo which I wanted to add myself several times but simply did not have the time for.
As for the changes to the expression builder, I was not really passionate about them in Paris, but I did not mind either way. However, looking at this PR, I think they would be better implemented as methods on the definition builders, and validated directly by the nodes:
```php
$builder->integerNode('foo')->range(1, 4)->end();
$builder->integerNode('foo')->mustBeGreaterThan(5)->end();
```
This will also allow for these constraints to be introspected and added to generated documentation.
---------------------------------------------------------------------------
by fabpot at 2012-07-03T17:57:25Z
@jeanmonod Can you take into account the comments by @schmittjoh?
---------------------------------------------------------------------------
by jeanmonod at 2012-07-03T19:40:24Z
@fabpot Yes, I will try to move those 4 checks.
@schmittjoh If I put those tests into the ScalarNodeDefinition did you think it's ok? And did I have to make anything special for the documentation introspection?
---------------------------------------------------------------------------
by schmittjoh at 2012-07-03T19:56:00Z
You can take a look at the EnumNodeDefinition, and the EnumNode. They are
pretty simple, and should give you a good idea of how to implement it.
On Tue, Jul 3, 2012 at 9:46 PM, Jeanmonod David <
reply@reply.github.com
> wrote:
> @fabpot Yes, I will try to move those 4 checks.
>
> @schmittjoh If I put those tests into the ScalarNodeDefinition did you
> think it's ok? And did I have to make anything special for the
> documentation introspection?
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/4714#issuecomment-6744309
>
---------------------------------------------------------------------------
by jeanmonod at 2012-07-03T21:37:18Z
OK, I just refactor as requested. At the end, I didn't add the range() check. It can be easily done by chaining min and max, like this:
$builder->integerNode('foo')->min(1)->max(4)->end();
@schmittjoh can you have a look?
---------------------------------------------------------------------------
by schmittjoh at 2012-07-03T21:48:17Z
Have you tested the builder API? Did you maybe forget to commit something?
---------------------------------------------------------------------------
by jeanmonod at 2012-07-03T21:52:45Z
Yes you are right, I forget the definition
---------------------------------------------------------------------------
by jeanmonod at 2012-07-03T22:15:45Z
OK, I realize now that I misunderstood the concept. I was thinking that a node was able to do self validation. But no, I will have to move my code to the node definition. So let's wait for a new commit...
---------------------------------------------------------------------------
by jeanmonod at 2012-07-06T06:13:55Z
@schmittjoh I just push the move to definition and the new abstract class Numeric. Can you review it?
---------------------------------------------------------------------------
by jeanmonod at 2012-07-10T05:12:59Z
@schmittjoh, @fabpot
I fix all the mention points, can you have a look at the final result?
---------------------------------------------------------------------------
by schmittjoh at 2012-07-10T06:38:20Z
There are still some excessive blank lines if you want to be perfect, but overall looks good now.
---------------------------------------------------------------------------
by jeanmonod at 2012-07-10T07:05:54Z
@schmittjoh I think the comments of @Baachi are not well placed in the diff. I execute php-cs-fix on all code, so level of perfectness is already good ;)
@fabpot Do you want some more complements before merging?
---------------------------------------------------------------------------
by fabpot at 2012-07-10T07:07:21Z
@jeanmonod I'm going to review the code once more and it will be merged for 2.2. Thanks for your work.
---------------------------------------------------------------------------
by fabpot at 2012-09-18T13:58:48Z
@jeanmonod Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by jeanmonod at 2012-09-18T14:36:59Z
@fabpot Squash done
---------------------------------------------------------------------------
by fabpot at 2012-09-19T04:07:13Z
@jeanmonod One last thing: can you submit a PR on symfony/symfony-docs that update the documentation with the new possibilities?
---------------------------------------------------------------------------
by jeanmonod at 2012-09-20T05:32:01Z
@fabpot OK, Documentation PR done here: https://github.com/symfony/symfony-docs/pull/1732
