Commits
-------
7f92833 [BrowserKit] Fixed cs.
df3da28 [BrowserKit] Using assertNull instead of assertEquals.
87890d3 [BrowserKit] Fixed CookieJar issue being unable to parse multiple cookies from Set-Cookie.
Discussion
----------
[BrowserKit] Fixed CookieJar being unable to parse multiple cookies
Fix proposition for #3109
My fix splits value of *Set-Cookie* header by comma. Than it checks each extracted part if it starts with a cookie-name (token). If check is positive cookie is added to the list. Otherwise it's appended to the previous value. First element is always added to the list.
[rfc6265](http://tools.ietf.org/html/rfc6265) defines cookie-name with token:
cookie-name = token
token = <token, defined in [RFC2616], Section 2.2>
token is defined in [rfc2616](http://tools.ietf.org/html/rfc2616#section-2.2) as follows:
token = 1*<any CHAR except CTLs or separators>
CHAR = <any US-ASCII character (octets 0 - 127)>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
That means cookie-name can be built out of following set of characters: *! # $ % & ' * + - . ^ _ ` | ~ 0-9 A-Z a-z*
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Commits
-------
100e97e [Filesystem] Fixed warnings in makePathRelative().
f5f5c21 [Filesystem] Fixed typos in the docblocks.
d4243a2 [Filesystem] Fixed a bug in remove being unable to remove symlinks to unexisting file or directory.
11a676d [Filesystem] Added unit tests for mirror method.
8c94069 [Filesystem] Added unit tests for isAbsolutePath method.
2ee4b88 [Filesystem] Added unit tests for makePathRelative method.
21860cb [Filesystem] Added unit tests for symlink method.
a041feb [Filesystem] Added unit tests for rename method.
8071859 [Filesystem] Added unit tests for chmod method.
bba0080 [Filesystem] Added unit tests for remove method.
8e861b7 [Filesystem] Introduced workspace directory to limit complexity of tests.
a91e200 [Filesystem] Added unit tests for touch method.
7e297db [Filesystem] Added unit tests for mkdir method.
6ac5486 [Filesystem] Added unit tests for copy method.
1c833e7 [Filesystem] Added missing docblock comment.
Discussion
----------
[Filesystem] Fixed a bug in remove() being unable to unlink broken symlinks
While working on test coverage for Filesystem class I discovered a bug in remove() method.
Before removing a file a check is made if it exists:
if (!file_exists($file)) {
continue;
}
Problem is [file_exists()](http://php.net/file_exists) returns false if link's target file doesn't exist. Therefore remove() will fail to delete a directory containing a broken link. Solution is to handle links a bit different:
if (!file_exists($file) && !is_link($file)) {
continue;
}
Additionally, this PR improves test coverage of Filesystem component.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
---------------------------------------------------------------------------
by cordoval at 2012-04-07T00:55:59Z
✌.|•͡˘‿•͡˘|.✌
---------------------------------------------------------------------------
by fabpot at 2012-04-07T06:12:34Z
Tests do not pass for me:
PHPUnit 3.6.10 by Sebastian Bergmann.
Configuration read from /Users/fabien/work/symfony/git/symfony/phpunit.xml.dist
.........................EE.......
Time: 0 seconds, Memory: 5.25Mb
There were 2 errors:
1) Symfony\Component\Filesystem\Tests\FilesystemTest::testMakePathRelative with data set #0 ('/var/lib/symfony/src/Symfony/', '/var/lib/symfony/src/Symfony/Component', '../')
Uninitialized string offset: 29
.../rc/Symfony/Component/Filesystem/Filesystem.php:183
.../rc/Symfony/Component/Filesystem/Tests/FilesystemTest.php:434
2) Symfony\Component\Filesystem\Tests\FilesystemTest::testMakePathRelative with data set #1 ('var/lib/symfony/', 'var/lib/symfony/src/Symfony/Component', '../../../')
Uninitialized string offset: 16
.../rc/Symfony/Component/Filesystem/Filesystem.php:183
.../rc/Symfony/Component/Filesystem/Tests/FilesystemTest.php:434
FAILURES!
Tests: 34, Assertions: 67, Errors: 2.
---------------------------------------------------------------------------
by jakzal at 2012-04-07T07:26:15Z
Sorry for this. For some reason my PHP error reporting level was to low to catch this...
Should be fixed now but I needed to modify the makePathRelative() (this bug existed before).
Commits
-------
6584721 [Form] Improved labels generated by default from form names
6e0b03a [Form] Fixed label of prototype in CollectionType
fc342d1 Merge remote branch 'umpirsky/collection-name' into issue3738
f91660d Added test for prototype label.
Discussion
----------
[Form] Fixed default label generated for the CollectionType prototype
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3738, #3739
Todo: -
![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue3738)
(the fact that the build fails seems to origin from the broken master)
Commits
-------
b6ac1aa [FORM] Give PropertyPath ability to read hassers
Discussion
----------
[Form] Give PropertyPath ability to read hassers
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Using a `hasser` instead of `isser` for Boolean values is pretty common. I've found myself using `issers` a handful of times just to make an interface play nice with the form component, but the code reads funny now. I don't think we should be accounting for every possible `getter` variation, but I think this one is common enough that it warrants a discussion.
---------------------------------------------------------------------------
by fabpot at 2012-03-11T08:25:31Z
I tend to agree with with. What do you think @bschussek?
---------------------------------------------------------------------------
by kriswallsmith at 2012-03-16T22:42:28Z
I'm not so sure. There are lots of reasons to write a *hasser* that accepts an argument (i.e. `User::hasRole($role)`). Doesn't seem as clean as *issers* and *getters*.
---------------------------------------------------------------------------
by vicb at 2012-03-16T22:49:14Z
> There are lots of reasons to write a hasser that accepts an argument
May be can check for 0 args as we are already using reflexion ?
---------------------------------------------------------------------------
by kriswallsmith at 2012-03-16T22:55:43Z
In that case we should check that there are either 0 arguments or only optional arguments and also consider adding the same logic to the other varieties.
---------------------------------------------------------------------------
by jjbohn at 2012-03-16T23:37:47Z
Passing arguments seems like a pretty big departure for PropertyPath. How would you annotate that? I'm not sure I see a common use case for needing arguments when mapping data to and from forms.
---------------------------------------------------------------------------
by stof at 2012-03-16T23:50:22Z
@jjbohn it is not about passing arguments but about using the hasser only if it does not have required arguments
---------------------------------------------------------------------------
by jjbohn at 2012-03-17T01:54:18Z
Ah. I see. I have a tendency to read @kriswallsmith comments wrong :D. I could see that but iirc, there's not any current check like this on the other accessors. Happy to add it though if there's a consensus.
---------------------------------------------------------------------------
by fabpot at 2012-03-17T11:24:34Z
What's the point is checking the hasser/getter/isser arguments. It's up to the developer to check if he can use them or not. Let's not complexify the code for this.
---------------------------------------------------------------------------
by kriswallsmith at 2012-03-17T15:37:39Z
My concern is that someone writes a hasser method on their model that is not intended for use with the form component but it's called anyway, leading to WTFs.
---------------------------------------------------------------------------
by stof at 2012-04-03T22:28:21Z
@fabpot what's your decision about this ?
@jjbohn you need to rebase your PR. It conflicts with master as tests have been moved
---------------------------------------------------------------------------
by bschussek at 2012-04-05T14:53:55Z
@kriswallsmith is right. The check for 1 === $method->getNumberOfRequiredParameters() can (and should) easily be added to all of the if-clauses here.
Apart from that, I'm okay with adding this.
Commits
-------
8689e9c [WIP] [Locale] Fixes NumberFormatter tests failing when using ICU 4.8 or 4.8.1
Discussion
----------
[WIP] [Locale] Fixes NumberFormatter tests failing when using ICU 4.8 or 4.8.1.1
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no
Todo: fix DateFormatter
The ICU CLDR 2.0 data has been updated on ICU 4.8 and the same data set is used on version 4.8.1.1. The problem is related to [this commit](http://bugs.icu-project.org/trac/changeset?reponame=&new=31307%40icu%2Ftrunk%2Fsource%2Fdata%2Fcurr%2Fen.txt&old=31074%40icu%2Ftrunk%2Fsource%2Fdata%2Fcurr%2Fen.txt) which has since been updated with new data and subsequently shipped with version 49.
The `DateFormatter` tests are still failing - see this [gist](https://gist.github.com/2004d40e5167286028ea). Suggestions are welcomed on how to handle this part.
Test results with PHP 5.4.0 with ICU 4.8.1.1 on OSX:
````
FAILURES!
Tests: 5917, Assertions: 12749, Failures: 26, Incomplete: 11, Skipped: 47.
```
with this WIP patch:
```
FAILURES!
Tests: 5917, Assertions: 12749, Failures: 13, Incomplete: 11, Skipped: 47.
```
Commits
-------
8ceb569 Fix typo
8702ea5 [Validator] Allow empty keys in the validation config
Discussion
----------
[Validator] Allow empty keys in the validation config
This allows you to just list fields that don't have validation rules (yet), for future reference it's kinda helpful. Right now if they're not commented out a fatal is thrown because null isn't an array.
---------------------------------------------------------------------------
by bschussek at 2012-04-05T15:34:09Z
Could you add a test please?
---------------------------------------------------------------------------
by Seldaek at 2012-04-05T15:34:48Z
The dummy key I added in the test makes it fail without the fix.
---------------------------------------------------------------------------
by bschussek at 2012-04-05T15:46:54Z
Ah, that's perfect, I overlooked that. Thanks!