[OptionsResolver] Fixed issues mentioned in the PR comments
Moved JSON encoding and decoding to separate classes which expose all their available parameters
[Form] Created failing test for PropertyPath modifying collections while iterating them
[Form] fix failing tests for remove call on an objectCollection
merged branch bschussek/issue4213 (PR #4284)

Commits
-------

9215c44 [Form] fix failing tests for remove call on an objectCollection
076a104 [Form] Created failing test for PropertyPath modifying collections while iterating them

Discussion
----------

[Form] Fixes PropertyPath not to remove elements while iterating a collection

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

![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=issue4213)

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

by travisbot at 2012-05-14T18:56:29Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1329584) (merged 9215c447 into 46ffbd52).
merged branch odolbeau/cs (PR #4278)

Commits
-------

3623580 Add missing PHPDoc

Discussion
----------

Add missing PHPDoc + correct PHPDoc alignment

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

by travisbot at 2012-05-14T15:19:29Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1327970) (merged 36235807 into 72b2f698).
[HttpKernel] fixed unit tests when run standalone (closes #4266, patch from Gator92)
added @ to all chmod() calls to avoid PHP warnings (operation not permitted) when using CIFS or NTFSa (closes #2125)
[WebProfilerBundle] re-added a div that were removed during the last update of the toolbar (closes #4265, #4282)
[Validator] Move doctrine/common dependency from require to suggest
[Validator] Change default of ValidatorFactory::buildDefault to exclude annotations
merged branch igorw/validator-suggest-doctrine-common-2.1 (PR #4290)

Commits
-------

4b0cdde [Validator] Change default of ValidatorFactory::buildDefault to exclude annotations
c7a8678 [Validator] Move doctrine/common dependency from require to suggest

Discussion
----------

[Validator] Move doctrine/common dependency from require to suggest

`doctrine/common` is only used for the annotations, so it should be made optional.

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

by travisbot at 2012-05-15T07:11:13Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1334026) (merged 4b0cdde2 into 114c34f8).
[OptionsResolver] Updated PHP requirements to 5.3.3
merged branch bschussek/options (PR #3968)

Commits
-------

95727ff [OptionsResolver] Updated PHP requirements to 5.3.3
1c5f6c7 [OptionsResolver] Fixed issues mentioned in the PR comments
d60626e [OptionsResolver] Fixed clear() and remove() method in Options class
2b46975 [OptionsResolver] Fixed Options::replace() method
16f7d20 [OptionsResolver] Improved implementation and clarity of the Options class
6ce68b1 [OptionsResolver] Removed reference to non-existing property
9c76750 [OptionsResolver] Fixed doc and block nesting
876fd9b [OptionsResolver] Implemented fluid interface
95454f5 [OptionsResolver] Fixed typos
256b708 [OptionsParser] Renamed OptionsParser to OptionsResolver
04522ca [OptionsParser] Added method replaceDefaults()
b9d053e [Form] Moved Options classes to new OptionsParser component

Discussion
----------

Extracted OptionsResolver component out of Form

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

![Travis Build Status](https://secure.travis-ci.org/bschussek/symfony.png?branch=options)

This PR refactors the options-related code of the Form component into a separate component. See the README file for usage examples.

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

by schmittjoh at 2012-04-17T18:11:03Z

To me it seems like we have some redundancy with the Config/Definition component. I'm wondering if these two can/should be merged somehow?

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

by kriswallsmith at 2012-04-17T18:14:44Z

I would also suggest merging this into the Config component. Its current name too closely resembles Python's optparser lib, which could create confusion.

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

by bschussek at 2012-04-17T18:18:49Z

Merge conflict artifacts are fixed now.

@schmittjoh Do we? Isn't the idea of the Config component to read complex configuration from different configuration providers? (YAML, XML, Annotations etc.)

The idea of this parser is to be highly performant and to be usable in simple classes. If this can be achieved with the Config component, I'm happy to learn more.

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

by schmittjoh at 2012-04-17T18:27:08Z

The config component is basically a super intelligent version of array_merge and the like.

About performance, I haven't really done any tests to say something about the impact. I think it's safe to say that it would be at least slower than your implementation in its current form due to the additional indirection. However, we could probably add a caching layer.

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

by bschussek at 2012-04-17T18:31:22Z

Have you checked the README I wrote? Are you sure the Config component is intended for the same purpose and not *way* too complex in this case?

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

by stof at 2012-04-17T18:51:14Z

You also forgot to update the ``replace`` section of the root composer.json file.

And regarding doing such thing with the Config Definition stuff, it would be more difficult: it builds the tree of values with their defaults, and then merges stuff coming from different sources. The form component however receives defaults from different places (which also define the allowed keys at the same time) and then receives user options only once. And it needs to handle easily default values which depend from other values. So I think both implementations are useful for different needs (however, we could argue about making it a subnamespace in the Config component, but this would add yet another different stuff in it)

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

by jalliot at 2012-04-17T18:58:03Z

@bschussek You need to add this component to the main composer.json too.

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

by lsmith77 at 2012-04-18T06:54:17Z

doesn't this overlap a bit with the ``TreeBuilder`` in the Config component?

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

by lsmith77 at 2012-04-18T06:59:12Z

ah just saw @stof's comment .. i think the biggest argument against TreeBuilder is that it was designed for a very specific purpose and performance wasn't one of them. where as Form needs something that performs fast. so yeah i do see different use cases, but i don't think this means we should have a new component.

furthermore while i haven't read the code in details i am surprised it doesn't make use of http://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.

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

by bschussek at 2012-04-18T08:10:49Z

@stof, @jalliot: Fixed.

> furthermore while i haven't read the code in details i am surprised it doesn't make use of http://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.

@lsmith77: Because that's not what this component does. The key feature of this component is to resolve default values of options that depend on the *concrete* values of other options. I invite you to read the README.

Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configurations from storage providers, such as the filesystem.

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

by bschussek at 2012-04-18T08:18:48Z

Note: Not all relevant code of this component is shown in the diff. The (crucial) Options and LazyOption classes have only been moved out of Form.

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

by lsmith77 at 2012-04-18T08:20:02Z

> Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configuration values from the filesystem (typically).

decoupled is all fine, but to me this feels a bit too granular. but i am just expressing a gut feeling here

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

by jalliot at 2012-04-18T08:34:03Z

I think too it should be included in the config component (maybe in a subnamespace). Indeed the behaviour is too different to be merged into the current component but its purpose is similar and is all about *configuration* (hence the name of the component). Otherwise we could also split the current Config component into smaller components as it seems to me there are already parts of it that are totally unrelated to each other.

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

by bschussek at 2012-04-18T11:30:55Z

@jalliot Can you go into detail which parts that are and what changes you suggest?

@kriswallsmith Any other naming suggestion?

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

by jalliot at 2012-04-18T11:34:35Z

@bschussek I don't know the current component well enough but that's the impression I had last time I looked at its code but I may be wrong.

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

by stof at 2012-04-18T19:30:43Z

@bschussek the Definition subnamespace of the Config component is standalone. It is not directly related to the Loader part

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

by bschussek at 2012-04-19T09:32:48Z

@stof So what do you recommend?

I think this is also a question of marketing. Is the Definition subnamespace intended to be used totally separately of the loaders? What are the use cases? If there are good use cases, it makes sense to me to extract the Definition part into a separate component. Otherwise not.

It is also a question of marketing, because the purpose of a component should be communicable in simple words (quoting @fabpot). The purpose of Config is (copied from the README):

> Config provides the infrastructure for loading configurations from different data sources and optionally monitoring these data sources for changes. There are additional tools for validating, normalizing and handling of defaults that can optionally be used to convert from different formats to arrays.

I think this purpose is completely different than that of OptionsParser.

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

by stof at 2012-04-19T11:39:50Z

The current description itself shows the current state: what is advocated as the main goal of the component (and was the original part) is the loader stuff. But the Definition part (mentioned as "additional tools") is bigger in term of LOC

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

by bschussek at 2012-04-19T11:55:17Z

@stof: Yes, this is a fact, but what's your opinion? How do we proceed with this PR?

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

by stof at 2012-04-19T12:21:44Z

Well, my opinion is that the current Config component may deserve to be split into 2 components (as someone may need only part of it). But this would be a huge BC break. @fabpot what do you think ?

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

by bschussek at 2012-04-23T10:14:57Z

@fabpot Can we merge this?

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

by fabpot at 2012-05-10T06:45:20Z

@bschussek I'm +1 for this PR but as mentioned by @kriswallsmith, we must find another name as `OptionsParser` immediately make me think of something related to the CLI.

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

by stof at 2012-05-10T06:47:45Z

However, after thinking about it again, I would vote for keeping it in its own component instead of adding yet another independant part in Config, to avoid forcing Form users to get the whole Config component

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

by bschussek at 2012-05-10T09:09:36Z

I'm having difficulties finding a better name. The main difference to CLI option parsers is that these actualy *parse* a string, while this class only receives an array of options (does not do any parsing). Otherwise both have the same purpose.

A couple of other suggestions:

* OptionsLoader (likely confused with our filesystem loaders)
* OptionsResolver
* OptionsMerger
* OptionsMatcher (not accurate)
* OptionsBuilder (likely confused with the builder pattern)
* OptionsJoiner
* OptionsBag (likely confused with the session bags)
* OptionsConfig (likely confused with Config)
* OptionsDefinition (likely confused with Config\Definition)
* OptionsSpec
* OptionsCombiner
* OptionsInitializer
* OptionsComposer

The difficulty is to find a name that best reflects its purpose:

```
$parser->setDefaults(...);
$parser->setRequired(...);
$parser->setOptional(...);
$parser->setAllowedValues(...)
$parser->parse($userOptions);
```

The only of the above examples that makes sense to me here is OptionsResolver -> resolve($userOptions).

Ideas?

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

by stof at 2012-05-10T09:56:54Z

OptionsResolver seems a better name than OptionsParser

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

by luxifer at 2012-05-10T09:59:45Z

Agree with @stof

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

by r1pp3rj4ck at 2012-05-10T10:03:53Z

I don't really like the plural in the name, but OptionsResolver seems better than OptionsParser. OptionResolver maybe?

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

by sstok at 2012-05-10T10:10:14Z

@r1pp3rj4ck Options makes more sense as they can be nested/deeper, and thus are multiple.

Agree with @stof also.

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

by r1pp3rj4ck at 2012-05-10T10:13:01Z

@sstok well, we have multiple events too and the name is EventDispatcher, not EventsDispatcher. Actually none of the component names are plural.

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

by newicz at 2012-05-10T10:33:50Z

OptionsResolver - I find it suggesting that there is some kind of problem to be resolved and there's not,
maybe OptionsDefiner but it isn't good aswell this is a tough one
merged branch Romain-Geissler/read-only-form-datamapper-fix (PR #4280)

Commits
-------

47605f6 [Form][DataMapper] Do not update form to data when form is read only

Discussion
----------

[Form] [DataMapper] Read only form datamapper fix

The current 2.0.13 ``Symfony\Component\Form\Extension\Core\DataMapper\PropertyPathMapper`` enables to overwrite data from form values, no matter the form fields are read only or not.

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: -

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

by travisbot at 2012-05-14T15:50:02Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1328279) (merged 47605f63 into 72b2f698).

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

by bschussek at 2012-05-14T18:06:41Z

Forms don't bind when they are read only, so why is this change necessary?

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

by stof at 2012-05-14T19:29:45Z

@bschussek A read-only child will not be bound but the setter will still be called on the parent object for this field (with the old value), making it mandatory to define setters for read-only fields.

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

by Romain-Geissler at 2012-05-14T19:43:11Z

In my case, the property is still set through a setter even if the field for this property is read only. The problem is the setter is not called with the legacy value it held, but with the value given by the form. In my case the value is transformed from a string to an object by a ``DataMapper``, which returns ``null`` for an empty string/value. Thus, the setter is called with ``null`` instead of the previous non ``null`` value (and not always the same) it held.

This PR just prevent the setter for an object property marked as read only in the form definition from being called.

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

by bschussek at 2012-05-15T08:20:28Z

Ok, :+1: then
[FrameworkBundle] Added Russian plural messages
[OptionsResolver] Added methods isKnown() and isRequired()
merged branch robocoder/autoloader (PR #4168)

Commits
-------

b2afd9f use require instead of include
1ed8b72 Autoloader should not throw exception because PHP will continue to call other registered autoloaders.

Discussion
----------

[DoctrineBundle] Proxy autoloader should not throw exception

Also change 'require' to non-fatal '@include' in the event no file is generated.

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

by stof at 2012-05-01T06:13:34Z

The goal of the exception was to make debugging easier. And all Symfony2 autoloaders are using ``require``

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

by robocoder at 2012-05-01T16:09:04Z

I changed the include back to a require.

Whether or not the exception makes debugging easier is debatable.  But throwing an exception from an autoloader is both unconventional and unexpected given that (1) exceptions are propagated while php calls other registered autoloaders, and (2) php will throw a fatal error where the usage actually occurs if the class doesn't exist.

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

by fabpot at 2012-05-15T06:01:11Z

ping @beberlei

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

by beberlei at 2012-05-15T10:20:06Z

Its tricky, the message does try to give some additional information - but later autoloaders could handle this issue anyways. I guess the PR makes sense as users have absolutely no control over this autoloader and it should therefore behave less strictly.
merged branch scoolen/json-decode-params (PR #4283)

Commits
-------

38cbbe7 Moved JSON encoding and decoding to separate classes which expose all their available parameters

Discussion
----------

[Serializer][JsonEncoder] Exposed json_encode and json_decode params

In `JsonEncoder::decode()` you are unable to change the `$assoc` parameter from `json_decode`. I created two sub-classes that handle JSON encoding and decoding while exposing all the available parameters from `json_encode` and `json_decode`. You can now do this:

```php
$jsonEncoder = new JsonEncoder(new JsonEncode(JSON_HEX_TAG), new JsonDecode(true, 1024));
$serializer = new Serializer(array(), array($jsonEncoder));
```

Additionally I made `json_last_error()` available from `JsonEncoder`:
```php
$jsonEncoder->getLastEncodingError();
$jsonEncoder->getLastDecodingError();
```

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: N/A
Todo: -
License of the code: MIT
Documentation PR: -

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

by travisbot at 2012-05-14T18:46:16Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1329496) (merged 38cbbe71 into 46ffbd52).

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

by fabpot at 2012-05-15T05:07:04Z

ping @Seldaek / @lsmith77

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

by Seldaek at 2012-05-15T09:47:48Z

This looks fine to me, I asked him to submit the PR, but I wanted to get feedback from others.
fixed CS