[Validator] Allow empty keys in the validation config
Fix typo
Add isMethod() to Request object
update changelog
[HttpFoundation] Coding standards.
[HttpFoundation] Add more tests for casing
merged branch drak/ismethod (PR #3800)

Commits
-------

33881dd [HttpFoundation] Add more tests for casing
aec1339 [HttpFoundation] Coding standards.
bf33bd4 update changelog
3dc72cd Add isMethod() to Request object

Discussion
----------

[HttpFoundation] Add isMethod() to Request object.

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -

Justification is for convenience.

---------------------------------------------------------------------------

by hhamon at 2012-04-06T07:14:44Z

+1
merged branch Seldaek/validator_yaml (PR #3794)

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!
merged 2.0
merged branch ruimarinho/icu-48-fix (PR #3748)

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.
```
moved a fixture file
merged branch jjbohn/feature/property-path-hasser (PR #3549)

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.