Commits
-------
d3fee9b [Finder] ignoreDotFiles(true) filter does not match (issue #4106)
Discussion
----------
Fix for issue #4106 [Finder] ignoreDotFiles(true) filter does not match
I added new dot test files:
* .bar
* .foo/
* .foo/.bar
Changed the tests and made a fix to finder that seems to okay for me.
I hope my first PR is well arranged ;-)
If not I will be pleased to get feedback...
---------------------------------------------------------------------------
by vicb at 2012-05-11T10:20:51Z
Could you squash you commits ?
There is also an issue when `ignoreDotFiles(false)` is called twice, could you add a failing TC and fix the code ?
`$this->ignore = $this->ignore ^ static::IGNORE_DOT_FILES;` should be `$this->ignore = $this->ignore & ~static::IGNORE_DOT_FILES;`
---------------------------------------------------------------------------
by travisbot at 2012-05-11T12:43:53Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1304510) (merged 72c320bc into ff7c4757).
---------------------------------------------------------------------------
by vicb at 2012-05-11T13:09:32Z
You need to:
- tackle the related issue I have mentioned,
- squash the commit,
- rebase,
- force push to your branch.
http://symfony.com/doc/current/contributing/code/patches.html has some more info.
As a fix, did you consider sending it to the 2.0 branch - your mention it as a BC in the commit comment but it really is a bug fix.
---------------------------------------------------------------------------
by jocl at 2012-05-11T13:33:30Z
Thank you. I will try it.
Hasn't ```ignoreVCS(false)``` the same twice calling problem with
```$this->ignore = $this->ignore ^ static::IGNORE_VCS_FILES;```?
---------------------------------------------------------------------------
by vicb at 2012-05-11T13:36:22Z
yep, good catch !
---------------------------------------------------------------------------
by jocl at 2012-05-12T10:32:06Z
I mentioned it as BC, since I found no place in documentation with the information that dotFiles are ignored by default. I was also wondering that it is default behavior.
But if I only read the code, it is a 100% bug.
As soon as the PR is merged, I think we should also add a little notice in documentation like it is for ignoreVCS():
http://symfony.com/doc/master/components/finder.html#files-or-directories
---------------------------------------------------------------------------
by fabpot at 2012-05-15T05:47:49Z
I think you should keep these changes on master. Last thing before I can merge: can you squash your commits as explained by @vicb?
---------------------------------------------------------------------------
by travisbot at 2012-05-15T08:20:04Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1334337) (merged 525919fa into ff7c4757).
---------------------------------------------------------------------------
by jocl at 2012-05-15T08:23:24Z
I am sorry, of wasting your time... totally confused about using git. I feel a little bit squashed :-) of a the possible actions.
I hope it is squashed now. And next time I will use the issue/ticket branch I made.
---------------------------------------------------------------------------
by fabpot at 2012-05-15T08:35:59Z
That's still not good. Squashing is explained here: http://symfony.com/doc/current/contributing/code/patches.html#rework-your-patch
---------------------------------------------------------------------------
by travisbot at 2012-05-15T20:44:14Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1339390) (merged d3fee9b2 into 03d4b026).
Commits
-------
fff7221 Fixed the proxy autoloading for Doctrine 2.2
Discussion
----------
Doctrine autoloading
This fixes the autoloading of proxies for Doctrine 2.2
---------------------------------------------------------------------------
by travisbot at 2012-05-17T22:36:11Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1361173) (merged fff72217 into b3799680).
Commits
-------
d1f0c25 Fixed the composer constraint for Doctrine Common
Discussion
----------
Common deps
This allows using Doctrine 2.2 when using the full repo as it is compatible. The workaround previously was to use the individual components as the deps was less strict in them.
Closes#4289
---------------------------------------------------------------------------
by travisbot at 2012-05-17T22:36:03Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1361187) (merged d1f0c254 into b3799680).
Commits
-------
189874d FileDumper does no backup.
Discussion
----------
FileDumper does no backup.
Backup check path missed a '/'. So no backup was made.
Removed the repeating path construction by replacing it by new variable.
---------------------------------------------------------------------------
by travisbot at 2012-05-16T14:14:58Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1345963) (merged 189874d0 into 5314836d).
Commits
-------
11e0d23 [HttpKernel] Fixed the BundleInterface
Discussion
----------
[HttpKernel] Fixed the BundleInterface
The kernel expects bundles to implement ContainerAwareInterface (a fatal
error occurs if the method is not implemented). This is done in the base
class but not enforced in the interface.
I spotted it when trying to mock the BundleInterface and pass the mock to the kernel. I created the branch based on master because it is changing the interface but I'm wondering if it should go in 2.0 instead as a bugfix. Someone implementing strictly the interface currently would not be able to use the kernel.
---------------------------------------------------------------------------
by travisbot at 2012-05-17T10:41:19Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1354421) (merged 11e0d232 into 5314836d).
The kernel expects bundles to implement ContainerAwareInterface (a fatal
error occurs if the method is not implemented). This is done in the base
class but not enforced in the interface.
Commits
-------
6341de0 Be more specific in phpdoc (Fixes#3216)
Discussion
----------
Modify TwigEngine.php's signature (#3216)
This fixes the "line-ending issues" in TwigEngine.php responsible for connection reset errors on windows (which do still occur on 2.0.13, when ```core.autocrlf``` is set to GitHub's recommendation rather than Symfony's), caused by factors out of Symfony's control.
I acknowledge the comments on the above issue, but it seems this is trivial to do and it will save a bunch of time for people who find themselves in this situation.
Bug fix: [no]
Feature addition: [no]
Backwards compatibility break: [no]
Symfony2 tests pass: phpdoc changes
Fixes the following tickets: [#3216]
License of the code: MIT
---------------------------------------------------------------------------
by travisbot at 2012-05-16T19:35:55Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1348808) (merged 6341de02 into 980a0620).
Commits
-------
3a5e84f [Validator] Add CollectionSize constraint
Discussion
----------
[Validator] Add CollectionSize constraint
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
I will also send a PR to the documentation as soon as this one is accepted.
---------------------------------------------------------------------------
by bschussek at 2012-04-29T08:24:28Z
-1
I dislike the rising amount of very specific constraints in the core. Can't we add this to Size?
---------------------------------------------------------------------------
by vicb at 2012-04-29T09:01:39Z
@bschussek #3918 implements what you propose but then the messages are not valid any more:
```php
<?php
public $minMessage = 'This value should be {{ limit }} or more';
public $maxMessage = 'This value should be {{ limit }} or less';
public $invalidMessage = 'This value should be a valid number';
```
I can imagine 2 solutions:
- adding some more message,
- rename the `Size` constraint to `Range` and create a new `Size` constraint for arrays / countables.
What do you think ?
---------------------------------------------------------------------------
by bschussek at 2012-04-29T09:27:53Z
I'd prefer the second solution and merge `Size` with `SizeLength` as well.
---------------------------------------------------------------------------
by vicb at 2012-04-29T09:34:50Z
@bschussek It would make sense. @makasim @Herzult any one of you would like to contribute this (i.e. rename the current Size to Range and create a new Size supporting arrays / countables / strings) ?
---------------------------------------------------------------------------
by Herzult at 2012-04-29T14:31:12Z
Yep, I'm on it.
---------------------------------------------------------------------------
by stof at 2012-04-29T15:22:44Z
@Herzult could you take the other comment into account and merge SizeLength into you Size ?
---------------------------------------------------------------------------
by vicb at 2012-04-29T15:33:05Z
The guessers should also be modified (it might also affect the ODM which is in an other repo, if so it would be good to sync the changes).
---------------------------------------------------------------------------
by Herzult at 2012-04-29T16:38:19Z
@stof the problem merging SizeLength into Size is that they don't have the same required options & messages.
---------------------------------------------------------------------------
by Herzult at 2012-04-29T16:47:40Z
And what about renaming Range to Interval and SizeLength to IntervalLength?
---------------------------------------------------------------------------
by stof at 2012-04-29T16:54:38Z
Well, SizeLength is about matching the length of a string currently. Nothing related to intervals
---------------------------------------------------------------------------
by Herzult at 2012-04-29T17:29:40Z
Here are the current names:
* **Size** for collection (countable) size
* **Range** for numbers
* **SizeLength** for strings
Merging **SizeLength** into **Size** is maybe not appropriate because collections and strings are different things. It'll be hard to find messages that fit both collections and strings. Maybe we had better to find a better name for both. What do you think?
About the ValidatorTypeGuesser, I'll update it as soon as we know ow to name the constraints.
---------------------------------------------------------------------------
by vicb at 2012-04-29T17:43:01Z
Size is a good name for both strings and "collections", could we have two sets of strings and select according to the type ?
---------------------------------------------------------------------------
by Herzult at 2012-04-29T22:39:55Z
I tried to merge them together, what do you think?
---------------------------------------------------------------------------
by vicb at 2012-04-30T06:52:37Z
I think your changes are great, may be @bschussek has more feedback. The ValidatorTypeGuesser and the translation are yet to be updated.
---------------------------------------------------------------------------
by hhamon at 2012-05-01T12:32:28Z
Am I missing something or `SizeLength` for strings is a duplicate for `MinLength` and `MaxLength` constraints?
---------------------------------------------------------------------------
by Herzult at 2012-05-02T13:29:36Z
Yep, that's true. But the only link between this PR and the SizeLength constraint is that I merged it to the one I introduced.
---------------------------------------------------------------------------
by Herzult at 2012-05-07T07:48:01Z
@bschussek what do you think?
---------------------------------------------------------------------------
by vicb at 2012-05-10T19:51:26Z
@Herzult this PR looks good to me, could you update the changelog and update guides, try to factorize the code and squash the commits ? Thanks.
---------------------------------------------------------------------------
by travisbot at 2012-05-11T15:42:35Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1306112) (merged 8d8e6443 into 4ac3bddb).
---------------------------------------------------------------------------
by vicb at 2012-05-11T21:42:21Z
* could #4259 be helpful ?
* please squash the commits.
* please create a PR / issue on [symfony-docs](https://github.com/symfony/symfony-docs)
thanks for the updates.
---------------------------------------------------------------------------
by travisbot at 2012-05-13T18:38:18Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1321123) (merged eeda9044 into 4ac3bddb).
---------------------------------------------------------------------------
by travisbot at 2012-05-13T18:45:12Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1321146) (merged 491ca19a into 8b54eb56).
---------------------------------------------------------------------------
by travisbot at 2012-05-14T11:29:39Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1326110) (merged 44865024 into 8b54eb56).
---------------------------------------------------------------------------
by vicb at 2012-05-14T11:49:37Z
@Herzult what about plural translations ?
---------------------------------------------------------------------------
by travisbot at 2012-05-14T16:52:37Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1328677) (merged 93480f95 into 46ffbd52).
---------------------------------------------------------------------------
by travisbot at 2012-05-14T17:03:13Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1328705) (merged 326c3b81 into 46ffbd52).
---------------------------------------------------------------------------
by vicb at 2012-05-14T20:19:18Z
thanks for the updates, this PR looks fine to me. @bschussek ?
---------------------------------------------------------------------------
by vicb at 2012-05-16T06:45:51Z
@Herzult can you squash your commits ?
---------------------------------------------------------------------------
by travisbot at 2012-05-16T11:20:44Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1344811) (merged 3a5e84f4 into 58b6ef23).
[Validator] Rename constraint Size to Range
[Validator] Rename constraint CollectionSize to Size
[Validator] Merge the SizeLength into the Size constraint
[Validator] Update messages in Size constraint for consistancy
[Validator] Add english and french translation for Size messages
[Validator] Tweak expected types for exceptions in SizeValidator
[Validator] Fix CS in SizeValidator
[Validator] Update the ValidatorTypeGuesser
[Validator] Tweak SizeValidator
[Validator] Update CHANGELOG
[Validator] Complete previous CHANGELOG updates
[Form] Update validator type guesser
[Validator] Pluralize collection size english messages
[Validator] Pluralize Size french messages
Commits
-------
d1c831d Change must-proxy-revalidate by proxy-revalidate
Discussion
----------
Change must-proxy-revalidate by proxy-revalidate
---------------------------------------------------------------------------
by travisbot at 2012-05-16T09:20:54Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1344060) (merged d1c831d7 into 8cd6cbcf).
Commits
-------
445fd2f In console terms columns are width and rows are height
Discussion
----------
[Console] Exchange terminal width and height
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
---------------------------------------------------------------------------
by travisbot at 2012-05-16T09:20:08Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1344055) (merged 445fd2f9 into 8cd6cbcf).
Added new dot files/folder:
* .bar
* .foo/
* .foo/.bar
Adapted unit tests to the new test directory structure.
Possible patch to fix Finder to ignore dot files.
And fixed issue if ignoreDotFiles(false) and ignoreVCS(false) is called twice.
Added 2 asserts to FinderTest.
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.
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.
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, 👍 then
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: -
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
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).
