This PR was merged into the master branch.
Commits
-------
b27b749 made usage of Composer autoloader for subtree-split unit tests
Discussion
----------
made usage of Composer autoloader for subtree-split unit tests
This PR also normalizes the way components are tested.
---------------------------------------------------------------------------
by stof at 2012-11-09T23:14:22Z
👍
This PR was merged into the 2.1 branch.
Commits
-------
646a714 Fix export-ignore on Windows
Discussion
----------
Fix export-ignore on Windows
Rules:
Tests/ export-ignore
don't work on Windows. My proposition is:
/Tests export-ignore
* 2.0:
[Form] Fixed NumberToLocalizedStringTransformer to accept both comma and dot as decimal separator, if possible
Show correct class name InputArgument in error message
shows correct class name InputOption in error message
The exception message should say which field is not mapped
[HttpFoundation] Fix name sanitization after perfoming move
Add check to Store::unlock to ensure file exists
Conflicts:
src/Symfony/Bridge/Doctrine/Validator/Constraints/UniqueEntityValidator.php
src/Symfony/Component/HttpFoundation/File/UploadedFile.php
tests/Symfony/Tests/Component/Console/Input/InputArgumentTest.php
tests/Symfony/Tests/Component/Console/Input/InputOptionTest.php
tests/Symfony/Tests/Component/Form/Extension/Core/DataTransformer/NumberToLocalizedStringTransformerTest.php
tests/Symfony/Tests/Component/HttpFoundation/File/FileTest.php
tests/Symfony/Tests/Component/HttpKernel/HttpCache/StoreTest.php
* 2.1:
[ClassLoader] fixed unbracketed namespaces (closes#5747)
slight refactoring in UrlMatcher
[Form] Created test for DoctrineOrmTypeGuesser see #5790
[Form] Fixed DoctrineOrmTypeGuesser to guess the "required" option for to-one associations
This PR was merged into the 2.1 branch.
Commits
-------
5d2525b [Form] Created test for DoctrineOrmTypeGuesser see #5790b844d6b [Form] Fixed DoctrineOrmTypeGuesser to guess the "required" option for to-one associations
Discussion
----------
[Form] Doctrine orm type guesser tests
This PR adds tests to https://github.com/symfony/symfony/pull/5790
---------------------------------------------------------------------------
by Tobion at 2012-10-20T10:53:56Z
Using real test entities would be better IMO. Using mocks ties it pretty much to the implementation.
---------------------------------------------------------------------------
by sstok at 2012-10-21T10:38:53Z
@Tobion thats true, but Doctrine Class meta data takes quite some coding to set-up.
For instance you need the EntityManager to get even get the meta data set!
So you'd end having more code to set-up then your actually testing.
---------------------------------------------------------------------------
by Burgov at 2012-10-21T12:58:58Z
I wasn't sure whether do use a test entity manager, or do it the way I finally did it.
@sstok true, it's quite some work to set it up, but on the other hand there's the base OrmTestCase class which does it for you, so it'd actually mean I'd only have to create one entity for all the cases: https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/Tests/DoctrineOrmTestCase.php
@Tobion on the other hand I tend to use a test EM only when I actually need to test persisting and loading, while this test case here is so isolated that I didn't really feel it would be necessary.
I'd like to know which method is preferred though, I'll change it if necessary, and other tests can be added to test the rest of this specific class
* 2.1:
fixed CS
added doc comments
added doc comments
[Validator] Updated swedish translation
Update src/Symfony/Component/Validator/Resources/translations/validators.de.xlf
[2.1] Exclude tests from zips via gitattributes
[HttpKernel][Translator] Fixed type-hints
Updated lithuanian validation translation
[DomCrawler] Allows using multiselect through Form::setValues().
[Translation] forced the catalogue to be regenerated when a resource is added (closes symfony/Translation#1)
Unit test for patched method OptionsResolver::validateOptionValues().
validateOptionValues throw a notice if an allowed value is set and the corresponding option isn't.
[Form] Hardened code of ViolationMapper against errors
[HttpFoundation] Fixed#5611 - Request::splitHttpAcceptHeader incorrect result order.
[Form] Fixed negative index access in PropertyPathBuilder
Update src/Symfony/Component/Validator/Resources/translations/validators.ro.xlf
Conflicts:
src/Symfony/Component/DomCrawler/Form.php
src/Symfony/Component/Process/Process.php
* 2.1:
[2.1] Fix SessionHandlerInterface autoloading
Remove executable bit from HttpKernel/DependencyInjection/ConfigurableExtension.php
[2.0][http-foundation] Fix Response::getDate method
[DoctrineBridge] Require class option for DoctrineType
[HttpFoundation] fixed the path to the SensioHandlerInterface class in composer.json
Support the new Microsoft URL Rewrite Module for IIS 7.0. @see http://framework.zend.com/issues/browse/ZF-4491 @see http://framework.zend.com/code/revision.php?repname=Zend+Framework&rev=24842
fixed undefined variable
hasColorSupport does not take an argument
Improve FilterResponseEvent docblocks Response ref
Commits
-------
83dc966 [Form] Fixed some PHPDoc
596bbb1 [Form] fixed FormConfigBuilder to use PropertyPathInterface
a523823 [Form] fixed and added phpDoc
Discussion
----------
[Form] fixed and added phpDoc
[ci skip]
---------------------------------------------------------------------------
by sstok at 2012-08-26T08:11:01Z
Some descriptions don''t seem to be properly aligned, use the CS-fixer.
---------------------------------------------------------------------------
by Tobion at 2012-08-26T17:02:25Z
@sstok This is more about manual fixes concerning forgotten exceptions or wrong data type. The cs fixer gives many false positives and can be applied later.
Commits
-------
f1c4b8b [Doctrine Bridge] Added a parameter ignoreNull on Unique entity to allow a nullable value on field. Added Test
Discussion
----------
[Doctrine Bridge] Added parameter ignoreNull to accept a nullable value on field
In my last project, i use this syntax to test unicity on 2 fields, but it fail because the validator stop if value is null. I dropped the test on validator and my unicity work fine.
```
@UniqueEntity(fields={"username", "deletedAt"})
```
It's possible to add this PR on Bridge.
Thanks
Bertrand
---------------------------------------------------------------------------
by stof at 2012-07-23T08:14:19Z
This is wrong. RDBMS allow several null values in a unique column and this change will break it.
---------------------------------------------------------------------------
by henrikbjorn at 2012-07-23T08:17:08Z
@stof seems weird indeed it would return if any of the values are null. Makes sense to do a query where the field `IS NULL` or whatever the find method does.
---------------------------------------------------------------------------
by stof at 2012-07-23T08:18:50Z
@henrikbjorn if you do a query with IS NULL, the validator would force to have only 1 entity with a null field whereas it is not the behavior of the DB-level constraint.
---------------------------------------------------------------------------
by henrikbjorn at 2012-07-23T08:20:41Z
In this case i suspect that he wants to achieve a `WHERE username = "henrikbjorn" AND deletedAt IS NULL` which would be valid right? Currently it just returns if any of the fields are null and the validation is never done.
---------------------------------------------------------------------------
by bschussek at 2012-07-23T08:27:24Z
I suggest to make this configurable as the handling of NULL values in UNIQUE columns [differs between SQL implementations](http://forums.mysql.com/read.php?22,53591,53591#msg-53591).
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T08:52:53Z
@stof What the correct solution to test my unicity with deletedAt == null ?
I use this definition: @ORM\Column(name="deleted_at", type="datetime", nullable=true)
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T20:28:44Z
In my local repository, i added a new parameter "$authorizedNullField" on UniqueEntity.php and tested this on UniqueEntityValidator.php:
Code: https://gist.github.com/4122efbe569e3c2c95c0
What about that ?
Thanks for your help
---------------------------------------------------------------------------
by stof at 2012-07-23T20:45:30Z
yep, this would be good (except for the naming which seems weird)
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T20:46:44Z
No problem to change this. I don't find a good name for this ?
---------------------------------------------------------------------------
by stof at 2012-07-23T20:47:57Z
what about ``allowMultipleNull`` (defaulting to ``true`` for BC) ?
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T20:51:30Z
Why multiple ? This option is for one or many. what about `allowNullable` ?
---------------------------------------------------------------------------
by stof at 2012-07-23T20:52:44Z
@Garfield-fr the current behavior allows having multiple null values without failing to the unique constraint
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T20:56:07Z
ok. I make `allowMultipleNull`.
It's ok with that: https://gist.github.com/cae8d43780c45a5011ed
Thanks
---------------------------------------------------------------------------
by bschussek at 2012-07-23T20:58:12Z
What about `uniqueNull` (`false` by default)? `ignoreNull` (`true` by default)? I find `allowMultipleNull` a bit cumbersome.
---------------------------------------------------------------------------
by stof at 2012-07-23T20:58:26Z
no it is not. You have an issue in the validator. You have an extra negation.
Please update your PR
---------------------------------------------------------------------------
by Garfield-fr at 2012-07-23T21:01:59Z
@stof `ignoreNull` is ok for you ?
---------------------------------------------------------------------------
by stof at 2012-07-23T21:10:24Z
yes
---------------------------------------------------------------------------
by fabpot at 2012-08-05T07:48:03Z
Is it mergeable now? Is yes, @Garfield-fr Can you squash your commits?
---------------------------------------------------------------------------
by travisbot at 2012-08-05T08:43:23Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2039523) (merged 19ae3cf9 into c20c1d18).
---------------------------------------------------------------------------
by stof at 2012-08-05T12:09:02Z
@Garfield-fr when squashing the commits, you need to force the push as you are rewriting the history. You should not have merged with your remote branch
---------------------------------------------------------------------------
by Garfield-fr at 2012-08-05T12:10:15Z
What's the right solution for resolve this ?
---------------------------------------------------------------------------
by stof at 2012-08-05T12:11:09Z
@Garfield-fr reset your local branch to the squashed commit and force the push
---------------------------------------------------------------------------
by Garfield-fr at 2012-08-05T12:14:09Z
@stof Thanks for your help
---------------------------------------------------------------------------
by travisbot at 2012-08-05T12:19:06Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2040210) (merged f1c4b8b4 into 20d2e5a1).
Commits
-------
24b764e [Form] Fixed issues mentioned in the PR
9216816 [Form] Turned Twig filters into tests
310f985 [Form] Added a layer of 2.0 BC methods to FormView and updated UPGRADE and CHANGELOG
5984b18 [Form] Precalculated the closure for deciding whether a choice is selected (PHP +30ms, Twig +30ms)
5dc3c39 [Form] Moved the access to templating helpers out of the choice loop for performance reasons (PHP +100ms)
0ef9acb [Form] Moved the method isChoiceSelected() to the ChoiceView class (PHP +150ms)
8b72766 [Form] Tweaked the generation of option tags for performance (PHP +200ms, Twig +50ms)
400c95b [Form] Replace methods in ChoiceView by public properties (PHP +100ms, Twig +400ms)
d072f35 [Form] The properties of FormView are now accessed directly in order to increase performance (PHP +200ms, Twig +150ms)
Discussion
----------
[Form] Made FormView and ChoiceView properties public for performance reasons
Bug fix: no
Feature addition: no
Backwards compatibility break: **yes**
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR changes the access to properties of `FormView` and `ChoiceView` objects from getters to direct property accesses. On [my example form](http://advancedform.gpserver.dk/app_dev.php/taxclasses/1) this improves rendering performance for **300ms** with PHP templates and **550ms** with Twig on my local machine.
Unfortunately, this breaks BC both with 2.0 and with the current master in Form Types and PHP templates. Twig templates are not affected by this change.
2.0:
```
$formView->set('my_var', 'foobar');
$formView->get('my_var');
$formView->getChild('childName');
$formView['childName'];
```
master:
```
$formView->setVar('my_var', 'foobar');
$formView->getVar('my_var');
$formView->get('childName');
$formView['childName'];
```
this PR:
```
$formView->vars['my_var'] = 'foobar';
$formView->vars['my_var'];
$formView->children['childName'];
$formView['childName'];
```
Should we add methods to keep BC with 2.0?
The second part of this PR contains improvements to the rendering of choice fields. These gain another **~500ms** for PHP templates and **80ms** for Twig. These improvements are BC, unless you overwrote the block "choice_widget_options" in your form themes which then needs to be adapted.
**Update:**
The PR now includes a BC layer for 2.0.
---------------------------------------------------------------------------
by stof at 2012-07-21T11:37:41Z
@bschussek couldn't we keep the getters and setters for BC even if the rendering accesses the public properties directly ?
---------------------------------------------------------------------------
by bschussek at 2012-07-21T11:52:33Z
@stof A BC layer for 2.0 is now included. People who upgraded to master already unfortunately need to adapt their code.
---------------------------------------------------------------------------
by sstok at 2012-07-21T12:40:57Z
👍
Commits
-------
8f99be3 [DoctrineBridge] Fixed the type guesser for doctrine 2.3
Discussion
----------
[DoctrineBridge] Fixed the type guesser for doctrine 2.3
Doctrine 2.3 now uses the drivers moved to Common, so the exception was not catched anymore and was breaking the guessing when a non-entity was used.
---------------------------------------------------------------------------
by craue at 2012-07-16T14:54:30Z
👍
---------------------------------------------------------------------------
by ddeboer at 2012-07-17T20:07:57Z
👍
---------------------------------------------------------------------------
by stof at 2012-07-17T20:17:01Z
@fabpot please merge this as 2.1 is currently broken when you rely on the form guessers for unmapped classes
Commits
-------
cd7835d [Form] Cached the form type hierarchy in order to improve performance
2ca753b [Form] Fixed choice list hashing in DoctrineType
2bf4d6c [Form] Fixed FormFactory not to set "data" option if not explicitely given
7149d26 [Form] Removed invalid PHPDoc text
Discussion
----------
[Form] WIP Improved performance of form building
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: **Update the Silex extension**
This PR is work in progress and up for discussion. It increases the performance of FormFactory::createForm() on a specific, heavy-weight form from **0.848** to **0.580** seconds.
Before, the FormFactory had to traverse the hierarchy and calculate the default options of each FormType everytime a form was created of that type.
Now, FormTypes are wrapped within instances of a new class `ResolvedFormType`, which caches the parent type, the type's extensions and its default options.
The updated responsibilities: `FormFactory` is a registry and proxy for `ResolvedFormType` objects, `FormType` specifies how a form can be built on a specific layer of the type hierarchy (e.g. "form", or "date", etc.) and `ResolvedFormType` *does the actual building* across all layers of the hierarchy (by delegating to the parent type, which delegates to its parent type etc.).
---------------------------------------------------------------------------
by schmittjoh at 2012-07-12T18:25:40Z
Maybe ResolvedFormType
---------------------------------------------------------------------------
by jmather at 2012-07-13T02:56:38Z
I really like ResolvedFormType. That's the naming method I took for my tag parser that handes the same conceptual issue.
---------------------------------------------------------------------------
by axelarge at 2012-07-13T05:25:00Z
ResolvedFormType sounds very clear.
This change is great and I desperately hope to see more of this kind
---------------------------------------------------------------------------
by Baachi at 2012-07-13T06:41:26Z
Yes `ResolvedFormType` sounds good :) 👍
---------------------------------------------------------------------------
by fabpot at 2012-07-13T07:11:33Z
I like `ResolvedFormType` as well.
---------------------------------------------------------------------------
by henrikbjorn at 2012-07-13T07:46:48Z
👍 `ResolvedFormType` :shipit:
---------------------------------------------------------------------------
by stof at 2012-07-13T18:01:51Z
This looks good to me
By default, the UniqueEntityValidator maps the violation on the first
field of the UniqueEntity constraint. The new option allows to control
this behavior if a better mapping is suited.
Commits
-------
a2b3d3c added cache service definition
Discussion
----------
[Doctrine Bridge] Added a method to load a cache definition
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Following this discussion (https://github.com/doctrine/DoctrineBundle/pull/62), this will let DoctrineBundle, MongodbBundle and CouchdbBundle share the same code for cache definitions.
---------------------------------------------------------------------------
by dlsniper at 2012-04-30T06:56:49Z
+1 for this PR.
---------------------------------------------------------------------------
by stof at 2012-04-30T06:57:58Z
👍
---------------------------------------------------------------------------
by fabpot at 2012-04-30T15:41:05Z
Can you add a note abou this change in the CHANGELOG?
---------------------------------------------------------------------------
by stof at 2012-04-30T15:46:48Z
does it really need to be in the changelog ? End-users don't know about this at all. The only guys affected by this change are the maintainers of the different Doctrine bundles as they can remove some code now.
---------------------------------------------------------------------------
by fabpot at 2012-04-30T16:41:21Z
@stof: right
@bamarni: Can you squash your commits?
---------------------------------------------------------------------------
by bamarni at 2012-04-30T17:03:38Z
@fabpot : done
---------------------------------------------------------------------------
by dlsniper at 2012-04-30T17:22:07Z
@bamarni can you also do a patch for the docs after this gets merged so that people know about this change and know how to use it?
Thank you!
---------------------------------------------------------------------------
by bamarni at 2012-04-30T17:29:05Z
@dlsniper : no problem ;)
---------------------------------------------------------------------------
by fabpot at 2012-04-30T18:29:03Z
ping @beberlei