Commits
-------
23bad29 Added translation to placeholder and title attributes
Discussion
----------
Added translation to placeholder and title attributes
---------------------------------------------------------------------------
by schmittjoh at 2012-05-03T13:52:38Z
Better translate it where it is defined.
Dynamic translations are usually not desirable as they cannot be automatically extracted, and thus require more work.
---------------------------------------------------------------------------
by ruimarinho at 2012-05-03T13:57:30Z
@schmittjoh but isn't that the same case as with labels for instance? I don't think injecting the translator service into the form type would require less work than what this PR suggests.
---------------------------------------------------------------------------
by schmittjoh at 2012-05-03T14:02:02Z
Yeah, same thing.
There might be some cases where it's fine, but in general, we should try to not translate dynamic vars.
---------------------------------------------------------------------------
by ruimarinho at 2012-05-03T14:17:44Z
@schmittjoh I think that's one of those cases, since these attributes in particular (title and placeholder) are intended to aid the user with a brief description. I understand (and agree) with your concern regarding dynamic vars, but in my opinion this is a use case where it is worth it. Just my two cents :)
---------------------------------------------------------------------------
by stof at 2012-05-03T18:07:01Z
@schmittjoh the issue is that translating the label before the template would require injecting the translator in the form types (as the form label can be set there) and would force the user to duplicate the translation process if they pass the label explicitly in the template.
Commits
-------
64101ab separate numeric value from suffix in File constraint's error message `$uploadIniSizeErrorMessage`
ff122d3 fixed tests
868d649 separate numeric values from suffixes in File constraint's error message `$maxSizeMessage`
Discussion
----------
[Validator] separate numeric values from suffixes in File validation error messages
This change allows me to locale-aware format the numbers in a form theme, i.e., to use a comma instead of a dot. If there's a better way without re-implementing the entire validator, let me know.
Such changes also allow for using a different separator than the usual space in translations.
---------------------------------------------------------------------------
by travisbot at 2012-05-08T19:14:16Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1278845) (merged f7c50098 into e54f4e46).
---------------------------------------------------------------------------
by travisbot at 2012-05-08T19:23:31Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1278940) (merged ce1cdafc into e54f4e46).
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-05-10T11:05:18Z
I don't know if there is a better way to do this, but I like the idea anyway.
---------------------------------------------------------------------------
by craue at 2012-05-11T14:18:52Z
Separated numeric values and suffixes for `$maxSizeMessage` and `$uploadIniSizeErrorMessage` now. Can't find any other relevant places (in other validators). Might be merged if accepted.
---------------------------------------------------------------------------
by travisbot at 2012-05-11T14:19:10Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1305246) (merged 438da7dd into e54f4e46).
---------------------------------------------------------------------------
by travisbot at 2012-05-11T21:22:25Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1309277) (merged 64101aba into dd0da03c).
---------------------------------------------------------------------------
by sstok at 2012-05-13T13:29:07Z
Using the NumberFormatter class would be an option, but that would also add a dependency when using Validation as stand-alone so using the {{ suffix }} is a good idea.
---------------------------------------------------------------------------
by craue at 2012-05-13T14:15:54Z
Using a NumberFormatter (if available) directly in the validator might indeed be a good option. In either case, having the numeric value separated from its suffix looks cleaner.
---------------------------------------------------------------------------
by craue at 2012-05-19T13:36:00Z
@fabpot: Would you merge this?
Commits
-------
fe7b258 Removed unnecessary use statements
Discussion
----------
[BrowserKit] Removed unnecessary use statements
Merely a cosmetical fix. My IDE (PhpStorm) marks the `use Symfony\Component\BrowserKit\Client;` statement in `Symfony/Component/BrowserKit/Client.php` itself as an error.
I also removed the two other `use`s of classes from the same namespace.
---------------------------------------------------------------------------
by travisbot at 2012-05-18T11:27:02Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1365455) (merged fe7b2583 into 1e15f210).
Commits
-------
46be121 added tokenDataExists() method to prevent loading complete profile structures upon writes
Discussion
----------
[HttpKernel] prevent loading complete profile structures upon writes
The abstract class "PdoProfilerStorage" uses its ::read() method to decide if a profiler record has to be updated or initially created upon a ::write() call. This possibly causes huge memory consumption, as ::read() recursively reads all existing profiles using ::createProfileFromData() calls. When handling many sub-request this may lead into either a "out of memory" or XDebug's "maximum nesting level reached" - whichever comes first.
To prevent this issue, I added a new protected method ::tokenDataExists() that simply checks whether a record for the token in question already exists in storage.
---------------------------------------------------------------------------
by travisbot at 2012-05-18T08:56:56Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1364303) (merged 46be1212 into 1e15f210).
Commits
-------
bc7043f [Routing] removed unused constructor arguments in test classes
d81fdfe [Routing] fixed namespace of test classes
53aaf76 [Routing] removed unused property of Router
Discussion
----------
[Routing] removed unused property of Router
Test pass: yes
BC break: no
This PR removes an unused property ($defaults) of Router. The property was passed to the constructor of UrlMatcher and UrlGenerator although these classes don't accept this parameter at all. And the dumped equivalents of them (produced by PhpMatcherDumper/PhpGeneratorDumper) don't need this property either.
So passing the $defaults was wrong and the property is not used in any way.
The DI config does not define anything for this property either: [routing.xml](https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Resources/config/routing.xml#L52)
The second commit fixes the namespaces of test classes that were wrong.
The third commit removes false arguments in the test classes.
---------------------------------------------------------------------------
by travisbot at 2012-05-22T07:34:03Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1397749) (merged bc7043f1 into e4e3ce6c).
Commits
-------
f883953 TypeGuess fixed for Date/Time constraints
41bed29 [Form] fixed invalid 'type' option in ValidatorTypeGuesser for Date/TimeFields
Discussion
----------
[Form] fixed invalid 'type' option in ValidatorTypeGuesser for Date/TimeFields
Automatic field type guessing breaks, if you use any of the Date/Time
constraints (i.e. Symfony\Component\Validator\Constraints\DateTime), since these field types have no 'type' option defined.
(See getDefaultOptions() in DateTimeType.php)
---------------------------------------------------------------------------
by travisbot at 2012-05-10T15:25:16Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1296309) (merged 005bdbb0 into 68eca0f9).
---------------------------------------------------------------------------
by travisbot at 2012-05-18T15:50:39Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1367774) (merged f8839532 into a04acc89).
---------------------------------------------------------------------------
by TonyMalz at 2012-05-18T15:58:57Z
@bschussek Ok, changed it to 'input'
---------------------------------------------------------------------------
by bschussek at 2012-05-22T08:18:27Z
👍
Commits
-------
4fa8e68 Add support for javascript object notation in allowed JSONP callback
Discussion
----------
Add support for javascript object notation in allowed JSONP callback
---------------------------------------------------------------------------
by travisbot at 2012-05-18T23:09:45Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1371497) (merged 4fa8e68c into 18132c18).
This reverts commit 5182a0c2c4.
PropertyPath instances should be empty. If you have an empty property path string, there is no need to create a PropertyPath instance for it.
Conflicts:
tests/Symfony/Tests/Component/Form/PropertyPathTest.php
Commits
-------
5d1b366 [Form] fix PhpDoc
Discussion
----------
[Form] fix PhpDoc
---------------------------------------------------------------------------
by travisbot at 2012-05-21T02:31:56Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1385372) (merged 5d1b3669 into 1407f112).
---------------------------------------------------------------------------
by vicb at 2012-05-21T05:44:03Z
have you used inheritdoc (over inheritDoc) on purpose ? (I must admin I haven't followed the CS discussion very closely)
---------------------------------------------------------------------------
by Tobion at 2012-05-21T16:16:48Z
Yes, inheritdoc is used on symfony. It's also the recommended way of phpdoc itself (all lower-case).
Commits
-------
0a3dd0f [Console] Check for existence of proc_open to fix#4338
Discussion
----------
[Console] Check for existence of proc_open to fix#4338
It is quite common to disable proc_open for security purposes.
This PR checks for the existence of the proc_open function and fixes Issue #4338
Replacement for PR4356
---------------------------------------------------------------------------
by travisbot at 2012-05-21T10:49:59Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1387784) (merged dd991bea into 1407f112).
---------------------------------------------------------------------------
by travisbot at 2012-05-21T11:35:21Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1387991) (merged 0a3dd0fe into 1407f112).
---------------------------------------------------------------------------
by fabpot at 2012-05-21T12:17:32Z
I forgot to ask you to sent a new PR for the 2.0 branch instead of master. Thanks.
---------------------------------------------------------------------------
by davidwindell at 2012-05-21T13:03:36Z
proc_open is not used in 2.0?
Commits
-------
a450d00 [HttpFoundation] HTTP Basic authentication is broken with PHP as cgi/fastCGI under Apache
Discussion
----------
[HttpFoundation] HTTP Basic authentication is broken with php-cgi under Apache
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #1813
Todo: -
In order to work, add this to the .htaccess:
RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]
---------------------------------------------------------------------------
by stof at 2012-03-10T17:34:26Z
you should also add a unit test for this
---------------------------------------------------------------------------
by kepten at 2012-03-11T15:34:04Z
Thanks for the feedback, I committed the changes.
---------------------------------------------------------------------------
by stof at 2012-04-04T01:59:53Z
@fabpot could you review it ?
---------------------------------------------------------------------------
by fabpot at 2012-04-04T07:15:34Z
My comments:
* `ServerBag` represents what we have in the `$_SERVER` global variables. As such, the code should be moved to the `getHeaders()` method instead like the other tweaks we do for the HTTP headers.
* A comment must be added explaining why this is needed and the configuration the user must have to make it work (then remove the Github URLs).
* The code should only be executed when `PHP_AUTH_USER` is not available (to not have any overhead when not needed).
---------------------------------------------------------------------------
by danielholmes at 2012-04-14T13:27:09Z
A quick note on that .htaccess/apache configuration required, if adding to the Symfony SE htaccess file, then it will need to look like this:
```
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ app.php [QSA,L]
</IfModule>
```
NOTE: No **,L** in the Authorization Rewrite as in the original example - it prevents the front controller rewrite from happening
---------------------------------------------------------------------------
by towards at 2012-04-20T16:12:49Z
@kepten you were faster than me applying @fabpot's comments :) nevertheless part of the bug hunt day I also modified the ServerBag class and tested them on a productive LAMP hosting server using Apache and FastCGI
---------------------------------------------------------------------------
by kepten at 2012-04-20T16:15:57Z
ok, so is my PR is useless or should I still fix problems?
---------------------------------------------------------------------------
by towards at 2012-04-20T16:20:26Z
your PR is fine for sure and I don't want to interfere, just wanted to mention that part of the bug hunt day of Symfony I had a go at this PR as an "exercise" but just saw later on that you already fixed the problem, so you can ignore my pushes
---------------------------------------------------------------------------
by vicb at 2012-04-20T16:20:36Z
I have been working with @towards: your PR is useful, please implement his comments and squash your PR.
---------------------------------------------------------------------------
by kepten at 2012-04-20T16:59:07Z
never squashed before, is it okay now? :)
---------------------------------------------------------------------------
by stof at 2012-04-20T17:21:07Z
it is
---------------------------------------------------------------------------
by vicb at 2012-05-20T19:57:51Z
@fabpot this should be ready to be merged
Commits
-------
fb6cf3e Allow for missing whitelines.
Discussion
----------
Allow for missing whitelines.
The Gettext specification allows for 'whitespace is optional' between message string.
For this to work PoFileLoader needs to save found messages on more places while processing. Thus a new method is introduced.
For the tests to work PoFileDumper was changed slightly to only emit white-lines when necessary.
I added more documentation from the GNU gettext documentation to make the code more understandable.
When [[BUG] PoFileLoader pluralhandling uses interval instead of index.](https://github.com/symfony/symfony/pull/4336) this patch needs some small rework.
(this is part of [[WIP]: Allow Drupal to use Translate component)](https://github.com/symfony/symfony/pull/4249)
---------------------------------------------------------------------------
by travisbot at 2012-05-19T12:44:19Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1374295) (merged fb6cf3ef into 58b92453).
---------------------------------------------------------------------------
by stof at 2012-05-19T13:19:29Z
you need to rebase your branch. github tells us it cannot be merged automatically
Commits
-------
dd60166 Fixed for allowing empty translation.
Discussion
----------
Fixed for allowing empty translation.
PoFileLoader should accept empty translations.
PoFileLoader calls array_filter just before returning the $messages thus filtering empty translations.
For Drupal we need to be able to load and then translate incomplete PO and POT files.
(this is part of [[WIP]: Allow Drupal to use Translate component](https://github.com/symfony/symfony/pull/4249))
---------------------------------------------------------------------------
by travisbot at 2012-05-19T11:14:39Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1373933) (merged 5ee0b1e6 into 58b92453).
---------------------------------------------------------------------------
by travisbot at 2012-05-19T12:09:48Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1374129) (merged dd601662 into 58b92453).
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
-------
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).
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
-------
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).
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
-------
ceb5ce6 [Form] fixed tests
a1e3a59 [TwigBridge] Switched to composer
df36afb [Form] Added tests
6d5ad3b [Form] Added right HTML types to Datetime/Date/Time types if single_text is true
Discussion
----------
[Form] Added right HTML types to Datetime/Date/Time types if single_text is true
When you set the `widget` option to `single_text`, you get a HTML input tag which is fine, but you the type is `text`, and it's wrong. You don't have any other way to get the right `type` as this attribute is defined to the FormView instance itself (see FileType for instance).
This PR adds right HTML types like the FileType does.
Cheers,
William
---------------------------------------------------------------------------
by willdurand at 2012-05-09T16:04:16Z
@fabpot anything else to do there?
---------------------------------------------------------------------------
by fabpot at 2012-05-11T16:28:43Z
adding some unit tests?
---------------------------------------------------------------------------
by willdurand at 2012-05-11T16:35:40Z
fair point :)
---------------------------------------------------------------------------
by travisbot at 2012-05-12T16:34:43Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1314731) (merged 2631c8b7 into cb905c5f).
---------------------------------------------------------------------------
by travisbot at 2012-05-12T17:14:12Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1314902) (merged ceb5ce6e into e1934527).
---------------------------------------------------------------------------
by willdurand at 2012-05-12T17:16:17Z
@fabpot ok, so I had to fix some other tests but there is a weird dependency between the tests in TwigBridge, and the Form component. I fixed the test suite's setup in the TwigBridge, and fixed some failing tests.
Commits
-------
6438c80 [Locale] Updated exception messages
Discussion
----------
[Locale] Updated exception messages
---------------------------------------------------------------------------
by travisbot at 2012-05-10T15:12:46Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1296098) (merged 60eabc7c into fae4523f).
---------------------------------------------------------------------------
by travisbot at 2012-05-11T21:27:29Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1309320) (merged 6438c808 into dd0da03c).
---------------------------------------------------------------------------
by hason at 2012-05-14T09:23:26Z
@fabpot corrected
Commits
-------
498b814 [FrameworkBundle] minor fix in TranslationUpdateCommand <info> was not properly closed.
Discussion
----------
[FrameworkBundle] TranslationUpdateCommand <info> was not properly closed.
---------------------------------------------------------------------------
by travisbot at 2012-05-13T13:43:06Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1319869) (merged 498b8140 into e1934527).
---------------------------------------------------------------------------
by fabpot at 2012-05-13T17:06:25Z
Can you reopen a PR on the 2.0 branch as this is a bug fix? Thanks.
---------------------------------------------------------------------------
by stof at 2012-05-13T18:09:39Z
@fabpot this command is a 2.1 feature (even if it was added 6 month ago and so seems already old). There is nothing to fix in 2.0
Since the redesign of the Web-Debug-Toolbar, a new PHP icon has been
set, but its color was a bit darker (#000000) than the other icons in
the toolbar (#302e32 for the Symfony2 logo). This commit aims to ajust
the background color of the PHP logo to keep a certain homogeneity.
