* 2.1:
[Yaml] fixed default value
Added Yaml\Dumper::setIndentation() method to allow a custom indentation level of nested nodes.
added a way to enable/disable object support when parsing/dumping
added a way to enable/disable PHP support when parsing a YAML input via Yaml::parse()
fixed CS
[Process] Fix docblocks, remove `return` from `PhpProcess#start()` as parent returns nothing, cleaned up `ExecutableFinder`
fixes a bug when output/error output contains a % character
[Console] fixed input bug when the value of an option is empty (closes#6649, closes#6689)
[Profiler] [Redis] Fix sort of profiler rows.
Fix version_compare() calls for PHP 5.5.
Removed underscores from test method names to be consistent with other components.
[Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)
Fix version_compare() calls for PHP 5.5.
Handle the deprecation of IntlDateFormatter::setTimeZoneId() in PHP 5.5.
removed the .gitattributes files (closes#6605, reverts #5674)
[HttpKernel] Clarify misleading comment in ExceptionListener
Conflicts:
src/Symfony/Bundle/WebProfilerBundle/Resources/views/Profiler/toolbar_style.html.twig
src/Symfony/Component/Form/Tests/Extension/Core/Type/DateTimeTypeTest.php
src/Symfony/Component/Form/Tests/Extension/Core/Type/TimeTypeTest.php
src/Symfony/Component/Form/Tests/Util/PropertyPathTest.php
src/Symfony/Component/HttpKernel/Profiler/RedisProfilerStorage.php
src/Symfony/Component/Process/Process.php
This PR was merged into the 2.1 branch.
Commits
-------
4991607 Fix version_compare() calls for PHP 5.5.
34def9f Handle the deprecation of IntlDateFormatter::setTimeZoneId() in PHP 5.5.
Discussion
----------
[Form] [Locale] PHP 5.5 compatibility fixes
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: N/A
Todo: None
License of the code: MIT
Documentation PR: N/A
IntlDateFormatter::setTimeZoneId() is deprecated in PHP 5.5, which results in E_DEPRECATED errors when using the date form type. This PR works around that.
Furthermore, the version_compare() tests used in locale to detect PHP 5.5 are broken with snapshot and Git builds of PHP. I've also committed a fix for those tests in this PR.
---------------------------------------------------------------------------
by stof at 2013-01-10T08:24:15Z
shouldn't it even be done in 2.0 as it is a bugfix ?
---------------------------------------------------------------------------
by LawnGnome at 2013-01-11T00:49:11Z
Possibly — I don't know enough about Symfony's release management to know whether this is appropriate for 2.0, and I was mostly scratching my own itch, honestly.
---------------------------------------------------------------------------
by stof at 2013-01-11T01:51:35Z
well, it is a bugfix and 2.0 is also impacted, so it should be done in it.
---------------------------------------------------------------------------
by LawnGnome at 2013-01-11T02:52:21Z
The diff for 2.0 looks like it'll be just the StubIntlDateFormatter.php changes — the deprecated method isn't called in DateType on that branch, and there aren't any StubIntlDateFormatter tests on 2.0. How do you want that submitted — as a separate PR against 2.0?
---------------------------------------------------------------------------
by fabpot at 2013-01-11T07:20:18Z
@LawnGnome A separate pull request would be good. Thanks.
---------------------------------------------------------------------------
by LawnGnome at 2013-01-11T08:29:48Z
2.0 PR added as #6699.
It is more common to use fully camel-cased names for test methods. Only some of the test methods are called with underscore notation. To avoid confusion it is better to be consistent.
This PR was merged into the master branch.
Commits
-------
6b1652e [PropertyAccess] Property path, small refactoring, read/writeProperty to read/write Property/Index.
1bae7b2 [PropertyAccess] Extracted PropertyAccess component out of Form
Discussion
----------
[PropertyAccess] Extracted PropertyAccess component out of Form
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
TODO: adapt DoctrineBundle/PropelBundle to pass the "property_accessor" service to EntityType/ModelType
Usage:
```php
$accessor = PropertyAccess::getPropertyAccessor();
// equivalent to $object->getFoo()->setBar('value')
$accessor->setValue($object, 'foo.bar', 'value');
// equivalent to $object->getFoo()->getBar()
$accessor->getValue($object, 'foo.bar');
// equivalent to $object->getFoo()['bar']
$accessor->getValue($object, 'foo[bar]');
// equivalent to $array['foo']->setBar('value')
$accessor->setValue($array, '[foo].bar', 'value');
// equivalent to $array['foo']['bar']
$accessor->getValue($array, '[foo][bar]');
```
Later on, once we have generation and caching of class-specific accessors, configuration will be something like this (consistent with the Form and Validator component):
```php
$accessor = PropertyAccess::getPropertyAccessorBuilder()
->setCacheDirectory(__DIR__ . '/cache')
->setCacheLifeTime(86400)
->enableMagicGetSet()
->enableMagicCall()
->getPropertyAccessor();
```
or
```php
$accessor = PropertyAccess::getPropertyAccessorBuilder()
->setCache($cache)
->getPropertyAccessor();
```
etc.
---------------------------------------------------------------------------
by Burgov at 2013-01-07T08:48:15Z
+1. I use this feature outside of the Form context a lot
---------------------------------------------------------------------------
by stof at 2013-01-07T08:49:34Z
The classes in the Form component should be kept for BC (and deprecated) for people using the feature
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T10:02:19Z
YES YES YES 👍. Sorry for my enthusiasm, but I already copy pasted the PropertyPath class to some of my libraries to avoid linking to the whole Form component. I thus will be glad to officially use this component into my libraries via composer.
---------------------------------------------------------------------------
by norzechowicz at 2013-01-07T10:17:39Z
Same as @michelsalib to avoid linking full Form component I was using copied parts of code. Can't wait to use this component in my lib. 👍
---------------------------------------------------------------------------
by bschussek at 2013-01-07T10:43:41Z
I split away `getValue()` and `setValue()` from `PropertyPath` into a new class `ReflectionGraph`. The component is also named ReflectionGraph now.
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T10:47:10Z
I am not found of the name. What do you intend to do in the component more than what PropertyPath does ?
---------------------------------------------------------------------------
by bschussek at 2013-01-07T10:58:59Z
@michelsalib A `PropertyPath` is simply a string like `foo.bar[baz]`. `getValue()` and `setValue()` interpret this path. There may be different interpretations for the same path, so these methods were split into a new class.
I chose the name `ReflectionGraph` because the functionality is very similar to `ReflectionProperty`.
```php
$reflProperty = new ReflectionProperty('Vendor/Class', 'property');
$reflProperty->setValue($object, 'foo');
$reflGraph = new ReflectionGraph();
$reflGraph->setValue($object, 'property.path', 'foo');
```
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T11:00:42Z
What about naming it `Reflection`, maybe sometime we will want to add more reflection tools for classes, interfaces... ?
---------------------------------------------------------------------------
by bschussek at 2013-01-07T11:02:32Z
@michelsalib I doubt that we will do that. PHP's implementation is sufficient.
---------------------------------------------------------------------------
by vicb at 2013-01-07T11:03:57Z
> Backwards compatibility break: no
Really ?
---------------------------------------------------------------------------
by michelsalib at 2013-01-07T11:05:07Z
Well, that is just a suggestion. If I am the only one to oppose, I won't complain.
---------------------------------------------------------------------------
by bschussek at 2013-01-07T11:09:08Z
> Really ?
@vicb Would you please refrain from such meanginless comments in the future? I'm getting a bit tired of them. If you think that BC is broken somewhere, tell me where so that I can fix it.
---------------------------------------------------------------------------
by stof at 2013-01-07T11:09:43Z
@vicb There is no BC break as he kept deprecated classes for BC
---------------------------------------------------------------------------
by norzechowicz at 2013-01-07T11:13:12Z
@bschussek what do you think about some kind of factory for Reflection? This will prevent creating new Reflection objects each time you want to access properties values.
---------------------------------------------------------------------------
by vicb at 2013-01-07T11:18:47Z
@bschussek my point is that my comment is no more meaningless than closing #6453 because it will break BC.We could also keep BC by extending the classes in the new ns but in both cases BC will ultimately be broken (when the legacy classes are removed)
---------------------------------------------------------------------------
by vicb at 2013-01-07T12:23:45Z
@bschussek @stof I think that modifying the constructor signatures of `EntityChoiceList`, `FormType` are BC breaks (this is not an exhaustive list)
---------------------------------------------------------------------------
by bschussek at 2013-01-07T12:35:13Z
@vicb You are right. I added corresponding entries to the CHANGELOG and adapted the above description.
---------------------------------------------------------------------------
by vicb at 2013-01-08T13:39:13Z
@bschussek looking at this PR, I was wondering if an alternate syntax would make sense:
```php
<?php
$reflGraph = new ReflectionGraph($object);
// equivalent to $object->getFoo()->setBar('value')
$reflGraph['foo.bar'] = 'value';
// equivalent to $object->getFoo()->getBar()
$reflGraph['foo.bar'];
```
_Sorry for the off topic_
---------------------------------------------------------------------------
by vicb at 2013-01-08T13:49:46Z
The advantage of using such a `ReflectionGraph` factory is that it might be easier to return specialized reflection graphs, ie optimized instances (that would be cached).
---------------------------------------------------------------------------
by Toflar at 2013-01-08T14:49:54Z
I was also puzzled by the fact that there will be many `ReflectionGraph` instances although they don't have to. I'm with @vicb and I'd also vote for using the constructor to set the subject you're working on. Otherwise you'll repeat yourself over and over again by passing the subject - say `$object` - to `getValue()` or `setValue()`. If however you don't like the constructor thing then why do we have to have an instance of `ReflectionGraph` rather than just go for static methods and use `ReflectionGraph::getValue()` and `ReflectionGraph::setValue()`?
In my opinion there are a few methods that could be static anyway (especially some private ones) :)
But probably I misunderstood something as I'm just about to discover the SF components and don't have any experience working with them (so basically I just read the PR because of @bschussek's tweet :D)
Couldn't come up with any intuitive name for the component though :(
Generally when we talk about "getting" and "setting" values we call those things "mutators"...so `GraphMutator` might be more intuitive than the word `Reflection` :)
---------------------------------------------------------------------------
by Taluu at 2013-01-08T14:57:42Z
I like the last proposition made by @vicb (implementing `ArrayAccess` on `ReflectionGraph` - or whatever name will be chosen (`PathMutator` for example :D), and also specify which object should be worked on in the constructor rather than in each method).
Would this also be used in the `Validator` component ?
---------------------------------------------------------------------------
by stof at 2013-01-08T15:16:12Z
@Toflar A static ``ReflectionGraph::getValue()`` means you have a coupling to the implementation (as with any static call). The current implementation allows you to replace it with your own implementation as long as you implement the interface as it follows the DI pattern (as done in other places in Symfony).
@vicb The issue with ``$reflGraph = new ReflectionGraph($object);`` is that you cannot inject the ReflectionGraph anymore, as you need a new one each time. This would mean adding a ``ReflectionGraphFactory`` to be injected (and which could then be replaced by a factory using code generation). Using the constructor directly would not allow using a replacement based on code generation later. So the resulting code would more likely be
```php
$reflGraph = new ReflectionGraph();
$mutator = $reflGraph->getMutator($object);
// equivalent to $object->getFoo()->setBar('value')
$mutator['foo.bar'] = 'value';
// equivalent to $object->getFoo()->getBar()
$mutator['foo.bar'];
```
Btw, writing this, I find the naming Mutator suggested by @Taluu good when it concerns the setter, but quite weird when getting the value.
---------------------------------------------------------------------------
by Taluu at 2013-01-08T15:21:00Z
I was not the one to suggest though, it was @everzet. But then something like `PathAccessor`, as it is both a mutator and a getter ? I also like @stof suggestion, still in the idea of avoiding to have to put the object as an argument and also allowing to use an `ArrayAccess` interface..
---------------------------------------------------------------------------
by vicb at 2013-01-08T15:21:54Z
@stof your remark makes sense.
What about `Accessor`, the benefit being that it might well be the name of a coming PHP feature: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
---------------------------------------------------------------------------
by everzet at 2013-01-08T15:27:02Z
```php
$manager = new PropertyManager(new PropertyPath());
$num = $manager->getValue($object, 'foo.num');
$manager->setValue($object, 'foo.num', $num + 1);
$objectManager = new ObjectPropertyManager($object[, $manager]);
$num = $objectManager->getValue('foo.num');
$objectManager->setValue('foo.num', $num + 1);
$objectManager['foo.num'] += 1;
```
---------------------------------------------------------------------------
by bschussek at 2013-01-08T15:28:01Z
It might be me, but I don't like `ArrayAccess` to be misused for features like that. If I access a key in an array access structure, I expect it to be something like a collection, an associative array or a key value store. This class is neither.
Putting that aside, an accessor for a specific object might make sense, but I'm not sure about that yet.
```php
$reflObject->setValue('foo.bar', 'value');
$reflObject->getValue('foo.bar');
```
---------------------------------------------------------------------------
by stof at 2013-01-08T15:28:52Z
@vicb I would vote for PathAccessor then, as we are not doing simple accessor but accessors through a path in an object graph.
In my snippet above, we would then have a ReflectionGraph instance and a PathAccessor instance (``$mutator``).
Btw, I would also keep the methods ``setValue`` and ``getValue``. I find it more clear.
---------------------------------------------------------------------------
by bschussek at 2013-01-08T15:32:07Z
@stof But then we're rather left with the question of ReflectionGraph **vs.** PathAccessor. I don't think that the tiny interface difference (one global, one object-based) justifies the big naming difference.
---------------------------------------------------------------------------
by vicb at 2013-01-08T15:33:24Z
> This class is neither.
It might be `$pa['foo.bar[baz]'] = $pa['foo.bar']['baz'];` I don't know if it would help though.
---------------------------------------------------------------------------
by stof at 2013-01-08T15:35:51Z
@bschussek In my suggestion, ``ReflectionGraph`` is a factory for the PathAccessor objects. It is not accessing anymore itself (which would probably continue to cause issues to implement it with code generation). But the naming could indeed be changed to something else.
- Removed useless error handlers around FormEvent as the triggering has
been fixed in it.
- Enhanced the triggering of deprecation errors for places where the BC
method provide some user logic needing to be converted to a new way.
- Enhanced the deprecation messages to mention the replacement whenever
possible.
Until PHP 5.5 hits beta, the version number for Git builds is still 5.5.0-dev,
which is less than 5.5.0alpha1 according to version_compare(). This means that
the branches for 5.5 aren't being executed on 5.5 snapshots at present.
This PR was merged into the master branch.
Commits
-------
c1aff96 [Form] Fixed regression introduced when merging 2.1 into master
Discussion
----------
[Form] Fixed regression introduced when merging 2.1 into master
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: -
This PR was merged into the master branch.
Commits
-------
36197dc Fixed typos
Discussion
----------
Fixed typos
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Fixes the following tickets: -
Todo: -
License of the code: MIT
This PR was merged into the master branch.
Commits
-------
586a16e [Validator] Changed DefaultTranslator::getLocale() to always return 'en'
58bfd60 [Validator] Improved the inline documentation of DefaultTranslator
cd662cc [Validator] Added ExceptionInterface, BadMethodCallException and InvalidArgumentException
e00e5ec [Validator] Fixed failing test
cc0df0a [Validator] Changed validator to support pluralized messages by default
56d61eb [Form][Validator] Added BC breaks in unstable code to the CHANGELOG
1e34e91 [Form] Added upgrade instructions to the UPGRADE file
b94a256 [DoctrineBridge] Adapted DoctrineBridge to translator integration in the validator
c96a051 [FrameworkBundle] Adapted FrameworkBundle to translator integration in the validator
92a3b27 [TwigBridge] Adapted TwigBridge to translator integration in the validator
e7eb5b0 [Form] Adapted Form component to translator integration in the validator
46f751c [Validator] Extracted message interpolation logic of ConstraintViolation and used the Translation component for that
Discussion
----------
[Validator] Integrated the Translator in the Validator component
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #5844, #6117
Todo: -
License of the code: MIT
Documentation PR: -
This PR allows to replace the default message substitution strategy in the validator (`strtr()`) by passing an implementation of `Symfony\Component\Translation\TranslatorInterface`. The motivation for this are both #5844 and the need to replace the translation strategy in Drupal's integration of the Validator.
In the stand-alone usage of the validator, both the translator and the default translation domain can now be passed to `ValidatorBuilderInterface`:
```php
$validator = Validation::createValidatorBuilder()
->setTranslator(new MyTranslator())
->setTranslationDomain('validators')
->getValidator();
```
References:
* #5844
* #6117
* #6129
* [Add a validation framework to Drupal 8](http://drupal.org/node/1845546)
* [Add the symfony validator component to core despite Symfony potentially releasing BC-breaking updates after 2.3.](http://drupal.org/node/1849564)
---------------------------------------------------------------------------
by Tobion at 2012-11-28T08:53:25Z
no BC break? Looking at ValidatorBuilderInterface there is definitely one.
---------------------------------------------------------------------------
by bschussek at 2012-11-28T08:55:01Z
ValidatorBuilderInterface is not part of the stable API. You are not supposed to implement this interface.
---------------------------------------------------------------------------
by Tobion at 2012-11-28T09:01:07Z
We're not only documenting bc breaks for stable API, otherwise we could remove 90% of the upgrade file since few methods are tagged with API.
An interface that nobody should implement?
---------------------------------------------------------------------------
by bschussek at 2012-11-28T09:30:02Z
The question is what to consider a BC break. Something will always break for someone. Should we consequently mark everything as BC break? I don't think so.
For example, since 2.1, you are supposed to use `Validation::createValidator*()` for creating a validator. Because of that, I won't consider changing the constructor signature of `Validator` a BC break anymore from 2.1 on.
The same for the unstable interfaces. These are currently meant to be used only, that is, type hint against them and call their methods. But we don't guarantee that we won't add methods to them.
---------------------------------------------------------------------------
by Tobion at 2012-11-28T09:38:19Z
I agree that almost any change could be considered a BC break. So we probably need to better define what a BC break is and what not. Otherwise Symfony will stop evolving after 2.3 because from then on Fabien wanted to prevent BC breaks which is almost impossible in a strict definition of bc break.
---------------------------------------------------------------------------
by fabpot at 2012-11-28T11:37:22Z
BC breaks should always be documented, and we guarantee BC only for things tagged with @api. I'm going to update the docs to make things clearer.
---------------------------------------------------------------------------
by bschussek at 2012-11-28T13:09:57Z
@fabpot I documented these changes now in the CHANGELOG: af99ebb1206ac92889b7193ba1ecc12bf2617e85
Are we sure we want to document *all* BC breaks from now on, even in non-@api code? This could rather scare people looking at our changelogs (lots of BC BREAKS there).
---------------------------------------------------------------------------
by fago at 2012-11-28T17:29:58Z
Unfortunately, it turns out the symfony translator interface does not mach the Drupal translation system as well as we initally thought, see http://drupal.org/node/1852106. Given that, this would integrating the validator component into Drupal even harder, because it introduces the dependency on the (unwanted) translation component. :(
---------------------------------------------------------------------------
by stof at 2012-11-28T18:19:36Z
If this does not help Drupal anyway, maybe #5844 is a better way to manage translations for people using the validator outside forms ?
and the Drupal guys would simply follow a similar approach, but based on their own translator instead of the symfony one.
---------------------------------------------------------------------------
by fago at 2012-11-28T18:50:12Z
Yeah. The only problem I see with the approach of #5844 is that *after* validation only the translated messages are available. We'd need to have access to the untranslated messages also.
---------------------------------------------------------------------------
by fago at 2012-11-29T09:49:47Z
As our translation system handles translating pluralized messages differently, the current ExecutionContextInterface::addViolation() method poses a problem also. We need to pass on - both the single and plural - message, as the message gets chosen during translation, see http://api.drupal.org/api/drupal/core!includes!common.inc/function/format_plural/8
So maybe, we could allow adding an already created ConstraintViolation object also? Then, we could implement a "PluralConstraintViolation" class that takes both message templates.
---------------------------------------------------------------------------
by bschussek at 2012-12-03T15:52:36Z
I updated this PR to support pluralized messages by default in the validator. This should solve the problem of the Drupal guys, because their implementation of `TranslatorInterface::transChoice($id, $number, ...)` can now simply split the $id by pipes (`|`) and pass the parts to their own `format_plural($count, $singular, $plural, ...)` function.
For us, it breaks BC because translation catalog sources had to be adapted.
---------------------------------------------------------------------------
by fabpot at 2012-12-03T16:25:52Z
Most of the XLF files are broken (the end is missing now).
IIUC, we now have a hard dependency on the Translation component, which is something we wanted to avoid.
---------------------------------------------------------------------------
by fabpot at 2012-12-03T16:27:56Z
Oops, clicked on the "comment" button too fast.
So, the dependency is hard (you need to install the dep) but light as we only rely on the translation interface from the component (when using the default translator). It looks acceptable to me, especially because we now use Composer to manage dependencies.
---------------------------------------------------------------------------
by bschussek at 2012-12-03T16:54:10Z
@fabpot Thanks for the hint. Going to fix this.
---------------------------------------------------------------------------
by bschussek at 2012-12-04T11:34:43Z
@fabpot Fixed.
---------------------------------------------------------------------------
by bschussek at 2012-12-07T12:40:24Z
Is there anything missing for this PR to be merged?
* 2.1:
[Console] Fix style escaping parsing
[Console] Make style formatter matching less greedy to avoid having to escape when not needed
[Bundle] [FrameworkBundle] fixed indentation in esi.xml services file.
[Component] [Security] fixed PSR-2 coding violation in ClassUtilsTest class.
[Form] Fixed EntityChoiceList when loading objects with negative integer IDs
[TwigBundle] There is no CSS visibility of display, should be visible instead
[Form] corrected source node for a Danish translation
[DependencyInjection] fixed a bug where the strict flag on references were lost (closes#6607)
[HttpFoundation] Check if required shell functions for `FileBinaryMimeTypeGuesser` are not disabled
[CssSelector] added css selector with empty string
[HttpFoundation] Docblock for Request::isXmlHttpRequest() now points to Wikipedia
[DependencyInjection] refactored code to avoid logic duplication
[Form] Deleted references in FormBuilder::getFormConfig() to improve performance
[HttpFoundation] Update docblock for non-working method
Conflicts:
src/Symfony/Bundle/TwigBundle/Resources/views/Exception/trace.html.twig
src/Symfony/Bundle/TwigBundle/Resources/views/Exception/traces.html.twig
This PR was merged into the master branch.
Commits
-------
e0b4480 [Form] Removed separator characters between choice or text fields in DateType
Discussion
----------
[Form] Removed separator characters between choice or text fields in DateType
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
This commit was originally contained in #6217 (for 2.1) but then split away for master since it changes behavior.
* 2.1: (24 commits)
updated license year
Update src/Symfony/Component/HttpFoundation/Response.php
[Form] Fixed inheritance of "error_bubbling" in RepeatedType
[Form] Fixed DateType when used with the intl extension disabled.
[HttpFoundation] fix return types and handling of zero in Response
[HttpFoundation] better fix for non-parseable Expires header date
Fixed missing plural message in portuguese validator
Fix Expires when the header is -1
[DoctrineBridge] Allowing memcache port to be 0 to support memcache unix domain sockets.
[Console] fixed unitialized properties (closes#5935)
[Process] Prevented test from failing when pcntl extension is not enabled.
Revert "[DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option"
[Form] Fixed failing tests for DateTimeToStringTransformer.
[Locale] Fixed the StubLocaleTest for ICU versions lower than 4.8.
[Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
[Form] Fixed test regression introduced in #6440
[Tests] Fix namespaces
Fixed php doc of GenericEvent::__construct
HttpUtils must handle RequestMatcher too
use preferred_choices in favor of preferred_query
...
Conflicts:
src/Symfony/Bridge/Propel1/Form/ChoiceList/ModelChoiceList.php
* 2.0:
updated license year
Update src/Symfony/Component/HttpFoundation/Response.php
[Console] fixed unitialized properties (closes#5935)
[Bundle] [FrameworkBundle] fixed typo in phpdoc of the SessionListener.
bumped Symfony version to 2.0.21-DEV
updated VERSION for 2.0.21
updated CHANGELOG for 2.0.21
Conflicts:
src/Symfony/Bundle/SwiftmailerBundle/LICENSE
src/Symfony/Component/Filesystem/LICENSE
src/Symfony/Component/HttpFoundation/Response.php
src/Symfony/Component/HttpKernel/Kernel.php
This PR was merged into the 2.1 branch.
Commits
-------
6c5e615 [Form] Fixed DateType when used with the intl extension disabled.
Discussion
----------
[Form] Fixed DateType when used with the intl extension disabled
DateType's month select box returns timestamps when used with intl extension disabled (see #6485).
The reason for this is that stubbed formats use *L* instead of *M* for month representation. My fix is simply taking this into account when building array for the select box.
I didn't provide unit tests since they're disabled when intl extension is not enabled. I've only manually verified if the months array contains correct data.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #6485
Todo: -
License of the code: MIT
Documentation PR: -
---------------------------------------------------------------------------
by bschussek at 2013-01-03T17:41:47Z
Doesn't this call for fixing the stub instead of changing the Form component?
---------------------------------------------------------------------------
by stof at 2013-01-03T17:50:49Z
@bschussek L and M are both valid for the month in Intl
---------------------------------------------------------------------------
by jakzal at 2013-01-03T17:52:41Z
[StubIntlDateFormatter uses FullTransformer](https://github.com/symfony/symfony/blob/2.1/src/Symfony/Component/Locale/Stub/StubIntlDateFormatter.php#L206) to format the date. [FullTransformer supports both *L* and *M*](https://github.com/symfony/symfony/blob/2.1/src/Symfony/Component/Locale/Stub/DateFormat/FullTransformer.php#L50) formats. Both formats are treated interchangeably.
Tests were only failing at the end of the month. PHP uses current day if it is not passed. Since February was used in the test cases, date was being moved to the next month (February has less days than other months).
This PR was merged into the master branch.
Commits
-------
7533deb [Form] Prevent trigger of E_USER_DEPRECATED for new API
Discussion
----------
[Form] Prevent trigger of E_USER_DEPRECATED for new API
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 stof at 2012-12-19T13:54:33Z
This is wrong as FormEvent extends DataEvent and so is also an instance.
Thus, DataEvent should never be constructed anymore (Sf2 does not instantiate it asnd there is no reason to dispatch it elsewhere). The BC is for typehints, and so the useful E_USER_DEPRECATED would be when DataEvent is used as typehint (which is not possible to detect AFAIK)
---------------------------------------------------------------------------
by drak at 2012-12-19T14:07:33Z
So in that case I should check specifically for two class names. Remember the intention here is to NOT trigger an error when the NEW class `FormEvent` is used. I'll update the PR.
---------------------------------------------------------------------------
by Tobion at 2012-12-19T14:25:42Z
I like the solution with an overridden constructor more because using the new stuff will not have the performance penalty of calling `get_class` at all.
---------------------------------------------------------------------------
by stof at 2012-12-19T14:52:47Z
@drak and why not simply ``if (!$this instanceof FormEvent)`` ?
---------------------------------------------------------------------------
by drak at 2012-12-19T15:58:28Z
@stof - if that's ok - I was just assuming other classes might have inherited.
@Tobion - the problem is the private name property we have to call parent which will ultimately call the deprecated constructor.
---------------------------------------------------------------------------
by drak at 2012-12-19T15:59:25Z
How about this?
---------------------------------------------------------------------------
by stof at 2012-12-19T16:51:26Z
@drak if your class inherit from DataEvent instead of FormEvent, it is logical to get a deprecation warning
---------------------------------------------------------------------------
by stof at 2012-12-19T16:52:50Z
@drak I think this allows removing some special error catching in a few places in Form tests (and also in the Form class if it was added)
---------------------------------------------------------------------------
by drak at 2012-12-19T17:33:51Z
@stof - yes, the whole idea is, if you inherit from FormEvent, no warning. anything else, gives warning - that's what we want right?
PR squashed and ready from my side.
---------------------------------------------------------------------------
by drak at 2012-12-20T14:00:13Z
ping @fabpot
---------------------------------------------------------------------------
by bschussek at 2012-12-28T15:19:40Z
👍
This PR was merged into the master branch.
Commits
-------
16a196a [Form] Fix deprecated call method
Discussion
----------
[Form] Fix deprecated call method
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: -
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
---------------------------------------------------------------------------
by stof at 2012-12-21T13:21:50Z
This is wrong as the typehint of the constructor is still typehinting the old interface, and so this method is not available.
But the typehint should be changed to use the new interface anyway
---------------------------------------------------------------------------
by francoispluchino at 2012-12-26T09:11:49Z
@fabpot It's OK for you?
(The failure of the Travis test is caused by the DateTime Form test only in PHP 5.3.3)
---------------------------------------------------------------------------
by bschussek at 2012-12-28T15:00:51Z
Can you please squash the commits?
---------------------------------------------------------------------------
by francoispluchino at 2012-12-28T15:57:47Z
@bschussek OK, it's done.
* 2.1:
bumped Symfony version to 2.1.7-DEV
updated VERSION for 2.1.6
updated CHANGELOG for 2.1.6
[Form] Fix for `DateTimeToStringTransformer`
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
This PR was merged into the master branch.
Commits
-------
cda1621 Move FormInterface too
0544351 Move DeprecationErrorHandler to Test folder so it's not removed when building the zip file
f56a2b9Fix#6374 move FormBuilderInterface from Tests to Test
Discussion
----------
Fix#6374 move FormBuilderInterface from Tests to Test
---------------------------------------------------------------------------
by fabpot at 2012-12-16T07:47:55Z
Are there any other classes in the tests that might be useful for testing userland forms? ping @bschussek
---------------------------------------------------------------------------
by colinfrei at 2012-12-16T08:24:51Z
The DeprecationErrorHandler will need to be in the Test directory as well, as its handleBC method is used for handling BC code that's not in tests.
---------------------------------------------------------------------------
by colinfrei at 2012-12-16T09:06:51Z
Wanted to make a pull request to tvlooy's branch with the DeprecationErrorHandler stuff, but can't figure out how to do that - the commit is here: ec56379042
---------------------------------------------------------------------------
by stof at 2012-12-16T19:53:59Z
@fabpot The other extending interfaces provided for mocking purpose (as mocking an interface extending ``Traversable`` directly does not work). So we have FormInterface too at least
This PR was merged into the master branch.
Commits
-------
2f6507b [Form] Fixed failing test
Discussion
----------
[Form] Fixed failing test
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: -
This PR was merged into the master branch.
Commits
-------
6b10550 Merge branch 'master' of github.com:symfony/symfony into deprecationErrors
1d82112 [Form] Fix two cases where deprecated methods were being used
b8cdbdc [Form] Catch deprecation errors that are caused by BC code
ebcb432 [Form] [FrameworkBundle] catch deprecation errors in tests
c21b12e [Form] handle BC use of deprecated stuff in non-test-methods.
fc2be6d [Form] catch deprecated errors in tests
800a032 [Form] replace bindRequest() with bind(), as bindRequest is deprecated
d5b2638 [Form] Trigger errors for deprecated methods in Form Component
f3d6966 [Validator] Stop using deprecated methods
d57ad32 [Form] Catch deprecation errors when using deprecated methods/classes in tests
3241157 [Validator] Trigger errors for deprecations
1f9eb7f return value of handleError
b35de9e Handle errors using a custom error handler
f49704b trigger errors for deprecated methods in HttpFoundation component
Discussion
----------
trigger_error() for deprecations
See also #6173 and #6139.
Started triggering errors in the HttpFoundation component.
It seems as if most of the time the error is just duplicating the text in the @deprecation comment.
Any opinions on if duplicating the text is acceptable, or if fetching the comment text to output the error makes sense?
---------------------------------------------------------------------------
by Seldaek at 2012-12-04T13:39:42Z
IMO it's fine to just duplicate the `@deprecated` note in the message, since anyway this code is meant to be completely deleted, this duplication should not do much harm.
---------------------------------------------------------------------------
by fabpot at 2012-12-06T08:22:21Z
@colinfrei I've merged PR #6173. Do you have time to implement the `trigger_error()` call everywhere? Thanks.
---------------------------------------------------------------------------
by colinfrei at 2012-12-06T08:36:55Z
Yep I'll finish that, probably until the beginning of next week.
---------------------------------------------------------------------------
by bschussek at 2012-12-10T10:15:12Z
Thank you for working on this!
---------------------------------------------------------------------------
by fabpot at 2012-12-12T11:08:53Z
@colinfrei: Is this PR finished? Can I merge it?
---------------------------------------------------------------------------
by colinfrei at 2012-12-12T12:09:19Z
@fabpot not quite - I lost some work due to a computer crash over the weekend. The only thing open is fixing the tests for the Form Component and catching the cases where the Form Component intentionally uses deprecated stuff.
---------------------------------------------------------------------------
by colinfrei at 2012-12-15T07:32:28Z
@fabpot - finished adding trigger_errors and catching them in Tests and as needed.
Travis is failing, but that seems to be master being broken due to the Finder changes?
I changed a few cases where the code was using deprecated methods which wasn't necessary in my eyes, specifically 1d8211249b, 800a032f07, f3d696636a
This PR was merged into the master branch.
Commits
-------
4c833ac Added Galician translation
Discussion
----------
[Form] [Validator] added Galician translation
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
The parts not given in the format are reset to the corresponding values of
the UNIX base timestamp. For example, when parsing with the format "Y-m-d",
parsing
"2012-05-18"
now results in the date
"2012-05-18 00:00:00 UTC"
instead of
"2012-05-18 12:58:27 UTC"
as before, where the time part corresponded to the local server time.
Another example: When parsing with the format "H:i:s", parsing
"12:58:27"
now results in
"1970-01-01 12:58:27 UTC"
instead of
"2012-12-13 12:58:27 UTC"
as before, where again the date part corresponded to the local server time.
This behavior is now consistent with DateTimeToArrayTransformer and
DateTimeToLocalizedStringTransformer.
* 2.1:
[Console] Add support for parsing terminal width/height on localized windows, fixes#5742
[Form] Fixed treatment of countables and traversables in Form::isEmpty()
refactor ControllerNameParser
[Form] Fixed FileType not to throw an exception when bound empty
- Test undefined index #
Maintain array structure
Check if key # is defined in $value
Update src/Symfony/Component/Validator/Resources/translations/validators.pl.xlf
This PR was merged into the master branch.
Commits
-------
d5426f0 [Form] Add tests to prove that label is not rendered when is marked as false
120547c [Form][TwigBridge] Don't set label attributes if is marked as not to be rendered [Form][FrameworkBundle] Add option to disable rendering of label for fields
36e4556 [Form] Option for not displaying a label by setting label to false. [Form] Fixed formatting & translation ..
Discussion
----------
[Form] Added option for not displaying a form-label by setting label to false
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Replaces: #5421
@fabpot @BenjaminBeck: I was just not sure what to do with "table based" forms, so I left `<td></td>` rendered when there is no label, because I'm not sure that we can hide it easily.
---------------------------------------------------------------------------
by XWB at 2012-12-11T09:30:14Z
👍
* 2.1:
fixed CS
fixed CS
[Security] fixed path info encoding (closes#6040, closes#5695)
[HttpFoundation] added some tests for the previous merge and removed dead code (closes#6037)
Improved Cache-Control header when no-cache is sent
removed unneeded comment
Fix to allow null values in labels array
fix date in changelog
removed the Travis icon (as this is not stable enough -- many false positive, closes#6186)
Revert "merged branch gajdaw/finder_splfileinfo_fpassthu (PR #4751)" (closes#6224)
Fixed a typo
Fixed: HeaderBag::parseCacheControl() not parsing quoted zero correctly
[Form] Fix const inside an anonymous function
[Config] Loader::import must return imported data
[DoctrineBridge] Fixed caching in DoctrineType when "choices" or "preferred_choices" is passed
[Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
[HttpFoundation] fixed a small regression
Conflicts:
src/Symfony/Component/HttpFoundation/Tests/Session/Storage/Handler/MongoDbSessionHandlerTest.php
This PR was merged into the 2.1 branch.
Commits
-------
6e7e08f [Form] Fixed the default value of "format" in DateType to DateType::DEFAULT_FORMAT if "widget" is not "single_text"
Discussion
----------
[Form] Fixed the "format" option in DateType
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #6141
Todo: -
License of the code: MIT
Documentation PR: -
This PR fixes a regression introduced in #4839. To quote that PR:
> This PR changes DateType and DateTimeType to support HTML5 by default when setting the option "widget" to "single_text".
In reality, the "format" option now defaults to the HTML5 format always, not just when "widget" is "single_text". This is fixed here.
The second commit in this PR removes special characters between select/text fields. What, with German locale, was
```
<day input>.<month input>.<year input>
```
before is now
```
<day input><month input><year input>
```
This is the way date fields are represented on the majority of websites. If you *need* separators, you can have them by setting the "format" option to a custom value:
```php
$builder->add('myDate', 'date', array(
'format' => 'dd.MM.yyyy',
));
```
---------------------------------------------------------------------------
by fabpot at 2012-12-07T08:52:21Z
The second commit should probably be done on master and it changes the behavior.
---------------------------------------------------------------------------
by bschussek at 2012-12-07T12:23:22Z
Ok, I removed the second commit now and removed the entries from the CHANGELOG.
* 2.1: (29 commits)
[DependencyInjection] fixed composer.json
[Validator] Fix typos in validators.ru.xlf
Edited some minor grammar and style errors in russian validation file
Updated Bulgarian translation
[Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
[Form] simplified a test from previous merge
Update src/Symfony/Component/Form/Extension/Core/Type/FileType.php
fixed CS
Xliff with other node than source or target are ignored
small fix of #5984 when the container param is not set
Filesystem Component mirror symlinked directory fix
[Process][Tests] fixed chainedCommandsOutput tests
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
info about session namespace
fix upgrade info about locale
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
...
* 2.0:
[DependencyInjection] fixed composer.json
[Form] Updated checks for the ICU version from 4.5+ to 4.7+ due to test failures with ICU 4.6
fixed CS
small fix of #5984 when the container param is not set
fixed CS
Use better default ports in urlRedirectAction
Add tests for urlRedirectAction
Update src/Symfony/Component/DomCrawler/Tests/FormTest.php
Update src/Symfony/Component/DomCrawler/Form.php
[Security] remove escape charters from username provided by Digest DigestAuthenticationListener
[Security] added test extra for digest authentication
fixed CS
[Security] Fixed digest authentication
[Security] Fixed digest authentication
[SecurityBundle] Convert Http method to uppercase in the config
Use Norm Data instead of Data
Conflicts:
src/Symfony/Bridge/Doctrine/Form/EventListener/MergeCollectionListener.php
src/Symfony/Bundle/FrameworkBundle/Controller/RedirectController.php
src/Symfony/Component/DependencyInjection/composer.json
This PR was merged into the 2.1 branch.
Commits
-------
06ee53b [Form] improve error message with a "hasser" hint for PropertyAccessDeniedException
Discussion
----------
[Form] improve error msg w/ a "hasser" hint for PropertyAccessDeniedException
"Hasser" support was added under the 2.1 branch of the Form component
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no, but fails exactly the same as without this fix
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: symfony/symfony-docs#1958
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no, but fails exactly the same as without this fix
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: symfony/symfony-docs#1958
This PR was merged into the master branch.
Commits
-------
1858b96 [Form] Adapted FormValidator to latest changes in the Validator
1f752e8 [DoctrineBridge] Adapted UniqueValidator to latest changes in the Validator
efe42cb [Validator] Refactored the GraphWalker into an implementation of the Visitor design pattern.
Discussion
----------
[Validator] Refactored the Validator for use in Drupal
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: TODO
Drupal wants to use the Symfony Validator component in their next version. I was talking to @fago recently about the changes that we'd need to make and implemented these changes in this PR. I don't want to rush this, but the deadline is tight, since Drupal feature freeze is on December 1st and @fago needs at least a couple of days to integrate the Validator into Drupal.
This PR introduces two significant changes:
* Interfaces were created for all classes that constitute the Validator's API. This is were the PR breaks BC, because `ConstraintValidatorInterface::initialize()` is now type hinted against `ExecutionContextInterface` instead of `ExecutionContext`.
* The graph walker was refactored into an implementation of the Visitor pattern. This way, the validator was decoupled from the structure of the metadata (class → properties and getter methods) and makes it possible to implement a different metadata structure, as is required by the Drupal Entity API.
As a consequence of the API change, custom validation code is now much easier to write, because `ValidatorInterface` and `ExecutionContextInterface` share the following set of methods:
```php
interface ValidatorInterface
{
public function validate($value, $groups = null, $traverse = false, $deep = false);
public function validateValue($value, $constraints, $groups = null);
public function getMetadataFor($value);
}
interface ExecutionContextInterface
{
public function validate($value, $subPath = '', $groups = null, $traverse = false, $deep = false);
public function validateValue($value, $constraints, $subPath = '', $groups = null);
public function getMetadataFor($value);
}
```
No more juggling with property paths, no more fiddling with the graph walker. Just call on the execution context what you'd call on the validator and you're done.
There are two controversial things to discuss and decide (cc @fabpot):
* I moved the `@api` tags of all implementations to the respective interfaces. Is this ok?
* I would like to deprecate `ValidatorInterface::getMetadataFactory()` (tagged as `@api`) in favor of the added `ValidatorInterface::getMetadataFor()`, which offers the exact same functionality, but with a different API and better encapsulation, which makes it easier to maintain for us. We can tag `getMetadataFor()` as `@api`, as I don't expect it to change. Can we do this or should we leave the old method in?
I would like to decide the major issues of this PR until **Sunday November 25th** in order to give @fago enough room for his implementation.
Let me hear your thoughts.
This PR was merged into the 2.1 branch.
Commits
-------
84635bd [Form] allowed no type guesser to be registered
Discussion
----------
[Form] made the factory builder pass null when no type guesser registered
reopened#5422 against 2.1 as it's a bug fix
---------------------------------------------------------------------------
by stof at 2012-10-13T21:23:34Z
@fabpot anything left for this PR ?
---------------------------------------------------------------------------
by fabpot at 2012-10-14T09:41:29Z
@bamarni Can you add some unit tests and also update the FormExtensionInterface interface phpdoc as `getTypeGuesser` can now return `null`? Thanks. ping @bschussek
---------------------------------------------------------------------------
by bamarni at 2012-10-14T17:10:27Z
I've added a few tests covering this.
@fabpot : the phpdoc is already correct, it currently can return null, this only occurs with this convenient class.
---------------------------------------------------------------------------
by bschussek at 2012-10-16T07:43:41Z
This PR breaks FormFactory::createBuilderForProperty(), which expects a guesser to be present. Can you check the component for other uses of the guesser and add a null-check there?
---------------------------------------------------------------------------
by bamarni at 2012-10-16T10:57:54Z
I cannot find other places than the factory (searching for 'getTypeGuesser').
---------------------------------------------------------------------------
by bschussek at 2012-11-08T16:58:37Z
You should also adapt `FormRegistry::getTypeGuesser()` not to build a `FormTypeGuesserChain` if the array of guessers is empty. In that case it will return now `null` (adapt the doc block). We also need a different was of checking if the type guessers have already been parsed in FormRegistry. Otherwise the first if condition in `FormRegistry::getTypeGuesser()` will never become false. You could for example initialize the property `$guesser` to `false` and only set it to `null` after the first run of `getTypeGuesser()`.
---------------------------------------------------------------------------
by bamarni at 2012-11-08T18:40:00Z
good catch I had missed it! I've applied your suggestion in the latest commit. Do you see anything else before I squash?
---------------------------------------------------------------------------
by bschussek at 2012-11-08T18:45:15Z
A test for `FormRegistry::getTypeGuesser()` would of course be awesome.
---------------------------------------------------------------------------
by bamarni at 2012-11-08T18:52:13Z
Then it was already awesome! (see https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Form/Tests/FormRegistryTest.php#L252)
I've also added one for the null case if it's what you meant.
This PR was squashed before being merged into the master branch (closes#5888).
Commits
-------
2379d86 CS Fixes - Replaced "array of type" by "Type[]" in PHPDoc block
Discussion
----------
CS Fixes - Replaced "array of type" by "Type[]" in PHPDoc block
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no (but tests doesn't pass on master too). See Travis.
License of the code: MIT
Documentation PR: Not Applicable
Status: Finished
To improve support of the eclipse PDT pluggin (for autocompletion), I propose to change the array notation in PHPDoc blocks to match the phpDocumentor notation for "array of type".
Modifications are made for the following components:
- BrowserKit
- ClassLoader
- Config
- Console
- CssSelector
- DependencyInjection
- DomCrawler
- EventDispatcher (no changes)
- Filesystem (no changes)
- Finder
- Form
- HttpFoundation
- HttpKernel
- Locale
- OptionResolver (no changes)
- Process (no changes)
- Routing (no changes)
- Serializer (no changes)
- Templating
- Translation
- Validator
- Yaml (no changes)
- Security
- Stopwatch (no changes)
See Proposal https://github.com/symfony/symfony/pull/5852
---------------------------------------------------------------------------
by pborreli at 2012-11-01T15:19:27Z
will you make a PR for each component ? why not only one PR with one commit for each component instead ?
---------------------------------------------------------------------------
by raziel057 at 2012-11-01T15:32:39Z
Ok, I'm going try to do it.
---------------------------------------------------------------------------
by raziel057 at 2012-11-01T16:12:56Z
I would like to rename my branch from COMPONENT_Form to changes-phpdoc (as all modifications would be commited in only one branch), so I tried to execute the following command but I have an error.
git remote rename COMPONENT_Form changes-phpdoc
error: Could not rename config section 'remote.COMPONENT_Form' to 'remote.changes-phpdoc'
Do you know how to do it?
---------------------------------------------------------------------------
by pborreli at 2012-11-01T16:14:26Z
don't rename it, you will have to close and make another PR which is useless here, just edit the title.
---------------------------------------------------------------------------
by stof at 2012-11-01T16:16:17Z
and ``git remote rename`` is about renaming a remote repo, not a branch
---------------------------------------------------------------------------
by raziel057 at 2012-11-03T11:36:02Z
Is it normal that all my commit are duplicated? I would like just update my master and merge with my branch.
---------------------------------------------------------------------------
by fabpot at 2012-11-06T10:22:55Z
@raziel057 Can you rebase on master? That should fix your problem.
---------------------------------------------------------------------------
by fabpot at 2012-11-09T13:28:53Z
@raziel057 Can you finish this PR?
---------------------------------------------------------------------------
by Tobion at 2012-11-09T13:34:45Z
I'll do it for the routing component this evening because I know it by heart. ^^
---------------------------------------------------------------------------
by raziel057 at 2012-11-09T15:06:26Z
@Tobion ok Thanks!
@fabpot Yes, I will try to finish it this week end.
---------------------------------------------------------------------------
by raziel057 at 2012-11-11T13:04:07Z
@Tobion Did you already change PHPDoc in the Routing component?
---------------------------------------------------------------------------
by Tobion at 2012-11-11T15:21:18Z
@raziel057 Yes I'm working on it.
---------------------------------------------------------------------------
by Tobion at 2012-11-12T15:16:31Z
@raziel057 Done. See #5994
* 2.1: (24 commits)
forced Travis to use source to workaround their not-up-to-date Composer on PHP 5.3.3
[Routing] removed irrelevant string cast in Route
Fixed typo
Make YamlFileLoader and XmlFileLoader file loading extensible
[HttpKernel] fix typo
Fixed singularization of "prices"
[Form] Removed an exception that prevented valid formats from being passed, e.g. "h" for the hour, "L" for the month etc.
[HttpKernel] fixed Client when using StreamedResponses (closes#5370)
fixed PDO session handler for Oracle (closes#5829)
[HttpFoundation] fixed PDO session handler for Oracle (closes#5829)
[Locale] removed a check that is done too early (and it is done twice anyways)
Update src/Symfony/Component/Validator/Resources/translations/validators.fa.xlf
Adding new localized strings for farsi validation.
[HttpFoundation] moved the HTTP protocol check from StreamedResponse to Response (closes#5937)
[Form] Fixed forms not to be marked invalid if their children are already marked invalid
[Form] Excluded some tests in NumberToLocalizedStringTransformerTest which fail on ICU 4.4, but work on ICU 4.8
added missing tests from previous merge
[Form] Fixed NumberToLocalizedStringTransformer to accept both comma and dot as decimal separator, if possible
Fix export-ignore on Windows
Show correct class name InputArgument in error message
...
Conflicts:
.travis.yml
src/Symfony/Component/Form/Extension/Core/DataTransformer/NumberToLocalizedStringTransformer.php
This PR was squashed before being merged into the master branch (closes#5879).
Commits
-------
07bd5c6 Make non-instantiable utils classes consistent with each other
Discussion
----------
Make non-instantiable utils classes consistent with each other
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
As per discussion in #5875 turned out that we don't have a consistent way to define non-instantiatable classes.
I don't like `final` as it removes flexibility with no visible gain.
I don't like `abstract` since it's not specifically clear what is meant by that. Is this class not complete? Should it be extended?
This PR was squashed before being merged into the master branch (closes#5928).
Commits
-------
6a033f3 setData method also accepts objects. Doc should reflect this.
Discussion
----------
setData method also accepts objects. Doc should reflect this.
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: NA
Todo: None
License of the code: MIT
Documentation PR: None
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
This PR was merged into the 2.1 branch.
Commits
-------
4909bc3 [Form] Fixed forms not to be marked invalid if their children are already marked invalid
Discussion
----------
[Form] Fixed forms not to be marked invalid if their children are already marked invalid
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4359
Todo: -
License of the code: MIT
Documentation PR: -
This PR prevents unsynchronized forms from being marked invalid if any of their children is also unsynchronized (and thus also marked invalid). Displaying an invalid message twice does not help the user and, if used in conjunction with error bubbling, may lead to duplicate errors (see #4359).
* 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:
removed unused use statements
[Form] Adapted HTML5 format in DateTimeType as response to a closed ICU ticket
[2.1][HttpFoundation] Fixed Php doc in Request::get
bumped Symfony version to 2.1.4-DEV
updated VERSION for 2.1.3
update CONTRIBUTORS for 2.1.3
updated CHANGELOG for 2.1.3
merged branch jakzal/yamlDoubleQuotesDumperFix (PR #4320)
Conflicts:
src/Symfony/Component/HttpKernel/Kernel.php
This PR was squashed before being merged into the master branch (closes#5838).
Commits
-------
201f3e6 [Form] Fixed cannot unset string offsets in CsrfValidationListener
Discussion
----------
[Form] Fixed cannot unset string offsets in CsrfValidationListener
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: -
A php fatal error is happening when someone rewrite the entire form data for an object with a single input.
```
Fatal error: Cannot unset string offsets in vendor/symfony/symfony/src/Symfony/Component/Form/Extension/Csrf/EventListener/CsrfValidationListener.php on line 72
```
Example:
```html
<form action="/app_dev.php/post/create" method="post" >
<div id="posttype">
<div>
<label for="posttype_name" class="required">Name</label>
<input type="text" id="posttype_name" name="posttype[name]" required="required" maxlength="255" />
</div>
<div>
<label for="posttype_text" class="required">Text</label>
<textarea id="posttype_text" name="posttype[text]" required="required"></textarea>
</div>
<input type="hidden" id="posttype__token" name="posttype[_token]" value="83a1617c694fbdea43c2527f1a55c7419ce82a42" /></div>
<p>
<button type="submit">Create</button>
</p>
</form>
```
If someone alters the html to add a simple input at the bottom of the form like this one:
```html
<input type="text" id="posttype" name="posttype" value="test123" />
```
The result will be a php fatal error.
---------------------------------------------------------------------------
by bschussek at 2012-10-26T09:49:05Z
Thank you for the pull request! Could you please reference the pull request in the test?
```php
// https://github.com/symfony/symfony/pull/5838
public function testStringFormData()
{
...
```
---------------------------------------------------------------------------
by jfcixmedia at 2012-10-26T10:21:29Z
@bschussek Added, thanks.
This PR was squashed before being merged into the master branch (closes#4115).
Commits
-------
878dd91 [2.2] [Form] Trim listener, unicode whitespace characters.
Discussion
----------
[2.2] [Form] Trim listener, unicode whitespace characters.
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo:
I have some questions. ZERO WIDTH SPACE (200B) doesn't belong to White_Space but it's invisible and treated as white space by the html4.1 spec - http://www.w3.org/TR/html4/struct/text.html#h-9.1
Same question for
* U+202F NARROW NO-BREAK SPACE
* U+FEFF ZERO WIDTH NO-BREAK SPACE
---------------------------------------------------------------------------
by Dattaya at 2012-04-26T09:49:25Z
It seems to me that the check `mb_check_encoding($data, 'UTF-8')` is unnecessary. For non utf8 characters `preg_replace` returns `null` if `u` flag is set.
From http://www.pcre.org/pcre.txt:
>When you set the PCRE_UTF8 flag, the byte strings passed as patterns
and subjects are (by default) checked for validity on entry to the rel-
evant functions.
...
>If an invalid UTF-8 string is passed to PCRE, an error return is given.
---------------------------------------------------------------------------
by Dattaya at 2012-07-27T06:52:58Z
Forgot to mention that `Cc` property includes more characters than needed (`0009-000D` and `0085`) but I think control characters shouldn't appear in a form field anyway.
---------------------------------------------------------------------------
by stof at 2012-10-13T16:47:47Z
@Dattaya ping
* 2.1: (28 commits)
Delete use of CreationExeption
[Form] Fixed error message in PropertyPath to not advice to use a non-existing feature
[Form] Fixed creation of multiple money fields with different currencies
[Form] Fixed setting the "data" option to an object in "choice" and "entity" type
Fixed Serbian plural translations.
Fixed IPv6 Check in RequestMatcher
Fix typo
change what I think is a typo
[Console] Fix error when mode is not in PATH
[WebProfilerBundle] fixed macro usage (to be forward compatible with Twig 2.x)
Change monolog require-dev to use the branch alias instead of dev-master
[FrameworkBundle] partially reverted previous merge
[2.1] Added missing error return codes in commands
Made the router lazy when setting the context
[WebProfilerBundle] fixed typos
Fix incorrect variable in FileProfilerStorage
UnitTest fix
UnitTest fix
added a unit test
fixed#5384
...
* 2.0:
[Form] Fixed creation of multiple money fields with different currencies
Fixed IPv6 Check in RequestMatcher
fixed DomCrwaler/Form to handle <button> when submitted
Conflicts:
tests/Symfony/Tests/Component/DomCrawler/FormTest.php
tests/Symfony/Tests/Component/Form/Extension/Core/Type/MoneyTypeTest.php
This PR was merged into the 2.1 branch.
Commits
-------
bda29b3 [Form] Fixed error message in PropertyPath to not advice to use a non-existing feature
Discussion
----------
[Form] Fixed error message in PropertyPath to not advice to use a non-existing feature
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5388
Todo: -
License of the code: MIT
Documentation PR: -
* 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
This PR was merged into the 2.1 branch.
Commits
-------
2568432 [Form] Hardened code of ViolationMapper against errors
Discussion
----------
[Form] Hardened code of ViolationMapper against errors
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
This ticket improves the code of ViolationMapper to reduce the risk of bugs and in order to make further bug fixing easier. It was implemented while trying to solve #5578 and is semantically equivalent to the previous version.
* 2.1:
Added Base64 encoding, decoding to MongoDBProfilerStorage
Fix duplicated code and a field name
refactor src/Symfony/Component/Translation/Loader/MoFileLoader.php
fixed typo
Update src/Symfony/Component/Validator/Resources/translations/validators.pl.xlf
fixed issue #5596 (Broken DOM with the profiler's toolbar set in position top)
[Form] Fixed the testsuite for PHPUnit 3.6 as travis still uses it
added dirs generated by build-data.php in locale component to .gitignore
[Process] Fixed bug introduced by 7bafc69f38.
[Process][Tests] Prove process fail (Add more test case)
[Process][Tests] Prove process fail
[HttpFoundation] Fixed the tests
[DomCrawler] Added test for supported encodings by mbstring
[Config] Fixed preserving keys in associative arrays
[Console] Fixed return value for Command::run
[Locale] Fixed tests
[Console] Fix some input tests
[Filesystem] Fixed tests on Windows
[Config] Fixed tests on Windows
* 2.1:
[Form] removed comment now that PHPUnit 3.7 is out
Add a Sigchild compatibility mode (set to false by default)
fix Fatal error: Cannot access private property
Conflicts:
src/Symfony/Component/Process/Process.php
Commits
-------
0f86a33 micro-optim: replace for with foreach
4efb9fe [Form] Remove unneeded FormUtil constants
Discussion
----------
[Form] Remove FormUtil constants
The constants are not useful from outside the class as the $pluralMap is also private. So no need to expose these veriables in the API when they cannot be used in any way. Unfortunately there are not private constants, so use private static. Then I realized the variables can be removed altogether, as they are only used once anyway and the index meaning is already documented in pluralMap.
---------------------------------------------------------------------------
by empire at 2012-08-18T12:58:22Z
FormUtils is abstract class, and maybe subclass (in future) will use this constants, I think changing access modifier to `protected` is better option.
---------------------------------------------------------------------------
by Tobion at 2012-08-18T12:59:40Z
They cannot, as pluralMap is private...
---------------------------------------------------------------------------
by Partugal at 2012-08-18T14:11:17Z
extract self::$pluralMap into local variable add small speed up
4.5499801635742 ms vs 5.7430267333984 ms on 100 iterations
---------------------------------------------------------------------------
by Tobion at 2012-08-18T14:16:47Z
This is not about performance.
---------------------------------------------------------------------------
by Partugal at 2012-08-18T14:21:11Z
yes but adds
your changes vs current is
5.7430267333984 ms vs 6.4971446990967 ms on 100 iterations
---------------------------------------------------------------------------
by Tobion at 2012-08-18T14:29:48Z
How about `$map =& self::$pluralMap[$i]`?
---------------------------------------------------------------------------
by Partugal at 2012-08-18T14:59:57Z
I mean https://gist.github.com/3387253
---------------------------------------------------------------------------
by Partugal at 2012-08-18T15:01:45Z
foreach is event faster :)
(4.1971206665039 ms on my hw)
---------------------------------------------------------------------------
by Tobion at 2012-08-18T15:04:51Z
I see.
---------------------------------------------------------------------------
by Partugal at 2012-08-18T15:06:41Z
in first comment i mean code like this:
```php
$pluralMap = self::$pluralMap; // do this because access to static property is to slow
```
on my machine & is slower `$map =& $pluralMap[$i]` vs `$map = $pluralMap[$i]`
5.0 vs 4.8 ms
imho & not needed in read only code
---------------------------------------------------------------------------
by Tobion at 2012-08-18T15:15:03Z
Well, you'd need to benchmark memory too. `=&` should reduce memory primarily in this case.
---------------------------------------------------------------------------
by Partugal at 2012-08-18T15:19:35Z
```php
echo memory_get_usage() . "\n"; // 711536
$a = array_fill(5, 6000, 'banana');
echo memory_get_usage() . "\n"; // 1497632
$b = $a;
echo memory_get_usage() . "\n"; // 1497760
$b[1] = 2;
echo memory_get_usage() . "\n"; // 2283832
```
1497760 - 1497632 = 128 it is size for variable structure not for its value:
```php
echo memory_get_usage() . "\n"; // 711536
$a = 1;
echo memory_get_usage() . "\n"; // 1497632
$b = &$a;
echo memory_get_usage() . "\n"; // 1497760
```
---------------------------------------------------------------------------
by Seldaek at 2012-08-18T17:52:32Z
@Tobion http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html - search for "copy-on-write" if you don't want to read it all.
---------------------------------------------------------------------------
by Tobion at 2012-08-18T19:37:44Z
Yeah I know about copy on write. I thought there might be a difference what you assign a sub-element of an array to a variable. But apparently not.
Interestingly `$a =& $b` takes a little more memory than `$a = $b` according to `memory_get_usage ()` but not when using `memory_get_usage (true)`.
---------------------------------------------------------------------------
by bschussek at 2012-08-30T08:15:01Z
I don't like the removal of the constants. They introduce meaning into the integers and improve code clarity. The rest looks good.
---------------------------------------------------------------------------
by Tobion at 2012-08-30T13:18:19Z
My opinion of the constants:
- They are part of the public API (as const are alwalys public) but cannot be used at all, as everything else is private...
- They are each only used once.
- The meaning of the indices is already documented in `$pluralMap`
- They are not used when building `$pluralMap` so they dont imprivate code clarity and consistence either. But doing so would on the other hand make it probably more ugly. So removing them is IMO best solution.
---------------------------------------------------------------------------
by bschussek at 2012-08-30T15:21:03Z
If you really need to remove the constants, then please comment the code where they are used accordingly.
---------------------------------------------------------------------------
by Tobion at 2012-08-31T00:58:51Z
I dont see what I should comment to make it more understandable, as the the map is already assigned to a named variable like `$suffixLength = $map[1];`.
---------------------------------------------------------------------------
by bschussek at 2012-08-31T09:12:18Z
> I dont see what I should comment to make it more understandable, as the the map is already assigned to a named variable
`$map[2]` and `$map[3]` is not self-describing.
---------------------------------------------------------------------------
by Tobion at 2012-08-31T17:23:15Z
@bschussek Done.
---------------------------------------------------------------------------
by bschussek at 2012-08-31T22:13:41Z
Could you please squash your commits?
They are part of the public API (as const are always public) but cannot be used at all from outside the class as the$pluralMap is private. The meaning of the indices is already documented in the array.
Commits
-------
58ebd1b [Form] Fixed error bubbling from DateTime widget - Issue #52708ea1607 Update src/Symfony/Component/Form/Extension/Core/Type/DateTimeType.php
Discussion
----------
[Form] Fixed error bubbling from DateTime widget - Issue #5270
This is related to https://github.com/symfony/symfony/issues/5270
---------------------------------------------------------------------------
by mpiecko at 2012-08-16T19:37:45Z
Travisbot shows something like this in it's log:
[Composer\Downloader\TransportException] The "http://nodeload.github.com/phingofficial/phing/zipball/2.4.12" file could not be downloaded (HTTP/1.1 500 Internal Server Error)
So is it my PR ot Travis CI who fails ... ? I saw this error in some other PR's ...
---------------------------------------------------------------------------
by stloyd at 2012-08-16T20:40:39Z
It's GitHub =)
---------------------------------------------------------------------------
by mpiecko at 2012-08-17T09:36:31Z
Bad GitHub :)
---------------------------------------------------------------------------
by bschussek at 2012-08-17T11:21:39Z
Could you please add a test to DateTimeTypeTest?
---------------------------------------------------------------------------
by mpiecko at 2012-08-17T12:23:40Z
Sure!
---------------------------------------------------------------------------
by bschussek at 2012-08-30T08:20:08Z
👍
Commits
-------
eb2eba1 [Form] don't allow users to force exceptions by submitting unexpected data
Discussion
----------
[Form] don't allow users to force exceptions by submitting unexpected data
fix#5334
This makes it more fault-tolerant by simply ignoring wrong stuff from hackers.
@bschussek: I didn't find any other UnexpectedTypeExceptions that could be invoked by simply submitting unexpected data. But I'm not 100% sure that there aren't any indirectly invokeable, e.g. in some listeners.
---------------------------------------------------------------------------
by stof at 2012-08-24T22:34:52Z
a test is missing for this.
---------------------------------------------------------------------------
by Tobion at 2012-08-24T23:02:26Z
@stof true, I will add one
---------------------------------------------------------------------------
by Tobion at 2012-08-25T13:51:23Z
Added test.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:07:37Z
👍
Could you please squash the commits?
---------------------------------------------------------------------------
by Tobion at 2012-08-29T13:43:52Z
Done.
Commits
-------
7e8ab54 [Form] raise OutOfBoundsException instead of InvalidArgumentException for inexistent form childs to be in line with PropertyPath
Discussion
----------
[Form] raise OutOfBoundsException instead of InvalidArgumentException in Form::get
BC break: yes
Raise OutOfBoundsException instead of InvalidArgumentException in Form::get for inexistent form childs to be in line with PropertyPath, which also uses OutOfBoundsException for invalid indexes. OutOfBoundsException fits much better as it extends RuntimeException instead of LogicException and this error can typically not be detected at compile time.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:01:01Z
👍
---------------------------------------------------------------------------
by stloyd at 2012-08-29T11:07:51Z
Shouldn't this change be noted in upgrade file ?
---------------------------------------------------------------------------
by stof at 2012-08-29T11:23:04Z
it should (and in the changelog of the component)
Commits
-------
e7e39e0 [Form] refactor Guess
dcbeeb1 [Form] replaced UnexpectedValueException by InvalidArgumentException in Guess
Discussion
----------
[Form] replaced UnexpectedValueException by InvalidArgumentException in Guess
BC break: yes
this is a better fit because the error is a logic exception (that can be detected at compile time, i.e. when writing the code) instead of a runtime exception
---------------------------------------------------------------------------
by bschussek at 2012-08-29T10:51:54Z
👍
Commits
-------
0186731 [Form] removed hasParent from FormInterface and deprecated its use
Discussion
----------
[Form] removed hasParent from FormInterface and deprecated its use
There are already 2 alternatives with getParent() and isRoot(), so a third one with similar semantics is confusing and unneeded.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:11:11Z
👍
Commits
-------
492c990 [Form] optimized PropertyPathMapper to invoke the expensive property path less often
47a8bbd [Form] optimized the binding of child forms and calculation of extra data
8d45539 [Form] refactor Form::bind to save 7 assignments
Discussion
----------
[Form] refactor Form::bind to save 7 assignments and a complete loop
---------------------------------------------------------------------------
by stof at 2012-08-24T23:45:18Z
the new code is not equivalent. See travis for the proof.
---------------------------------------------------------------------------
by Tobion at 2012-08-25T01:50:41Z
@stof fixed, I had to reduce the refactoring a little
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:05:52Z
👍
Commits
-------
d5eb4f7 [Form] fix phpdoc of Form::hasErrors
5cb8264 [Form] deprecated Form::hasErrors that isn't part of the Interface
Discussion
----------
[Form] deprecated Form::hasErrors that isn't part of the Interface
This method is not part of FormInterface, so I deprecated it as it cannot be used reliably. This is consistent with other hassers that were deprecated like `hasChildren` where one should use `count` instead.
---------------------------------------------------------------------------
by stof at 2012-08-26T19:11:19Z
You should deprecate it, not remove it
---------------------------------------------------------------------------
by Tobion at 2012-08-26T19:17:35Z
oh right. I thought it was added in 2.1 and thus can be removed but it's also in 2.0.
Done.
---------------------------------------------------------------------------
by bschussek at 2012-08-29T11:00:32Z
👍
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
-------
9e5d5a4 [Form] fix static method call
Discussion
----------
[Form] fix static method call
`allowDataWalking` was called statically, but wasnt defined as such.
Commits
-------
933e821 Add minimum-stability (dev) in each component
Discussion
----------
Add minimum-stability (dev) in each component
This fixes the ability to run the test suite in each component if a `composer install` is needed.
---------------------------------------------------------------------------
by stof at 2012-08-22T13:57:14Z
If you really want to run the testsuite standalone, some dev requirements are missing (SecurityBundle needs the FrameworkBundle for its functional tests for instance). If you have some time to check the missing dev requirement, it would be great.
Anyway, 👍 for this
---------------------------------------------------------------------------
by willdurand at 2012-08-22T13:59:15Z
Yes I already did that once. I'll try to fix more components later.
On Wed, Aug 22, 2012 at 3:57 PM, Christophe Coevoet <
notifications@github.com> wrote:
> If you really want to run the testsuite standalone, some dev requirements
> are missing (SecurityBundle needs the FrameworkBundle for its functional
> tests for instance). If you have some time to check the missing dev
> requirement, it would be great.
> Anyway, [image: 👍] for this
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/symfony/symfony/pull/5318#issuecomment-7934886>.
>
>
---------------------------------------------------------------------------
by stof at 2012-08-22T14:02:23Z
Well, I think most components should be good now (as some work has been done on them). But the bridges and bundles may need some work (bundles were not having any dev requirements until yesterday when @guilhermeblanco added some on FrameworkBundle)
---------------------------------------------------------------------------
by pborreli at 2012-08-22T14:14:00Z
what about having for each READ-ONLY repo his own .travis.yml and travisci hook activated ?
---------------------------------------------------------------------------
by fabpot at 2012-08-22T14:30:13Z
please, don't add more travis files. The main already tests everything, and that's all we need.
---------------------------------------------------------------------------
by stof at 2012-08-22T14:33:46Z
@pborreli tests should not be different for subtree split repos as the code is the same and the tests are the same (except that more tests could be skipped because of missing deps).
Note that for the bundles, it is likely to be different currently as I think some skip tests are missing (just like dev requirements are). But fixing this does not require enablign travis.
---------------------------------------------------------------------------
by pborreli at 2012-08-22T14:42:30Z
ok, i was just thinking about a way to be sure each component is usable individually but yeah that would require to relaunch each tests and add a bunch of travis files + hook
---------------------------------------------------------------------------
by hason at 2012-08-24T13:12:04Z
@stof, @eriksencosta, @fabpot: Tests are different for Locale component, see #5235
---------------------------------------------------------------------------
by stof at 2012-08-24T13:35:07Z
@hason no. You also need to do it when running the tests of the Locale component as part of the full run.
Commits
-------
a38232a [Form] Fixed: FormTypeInterface::getParent() supports returning FormTypeInterface instances again
Discussion
----------
[Form] Fixed: FormTypeInterface::getParent() supports returning FormTypeInterface instances again
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5221
Todo: -
---------------------------------------------------------------------------
by stof at 2012-08-22T14:14:55Z
the return value of the getParent method should be updated in the phpdoc of the FormTypeInterface to mention the FormTypeInterface .And the description of the method should be updated to explain than returning an instance is discouraged as it implies a performance penalty and does not support using type extensions (if the comment in the factory also applies to the unregistered parent)
---------------------------------------------------------------------------
by henrikbjorn at 2012-08-22T14:22:00Z
Wasn't TypeExtensions supported before? This means that Csrf will not be applied?
---------------------------------------------------------------------------
by stof at 2012-08-22T14:23:50Z
@henrikbjorn the csrf extension is targeting the FormType, which is registered in the form registry. What is not supported is having a type extension targeting an unregistered type
---------------------------------------------------------------------------
by bschussek at 2012-08-22T14:39:53Z
@stof Exactly. I find it a bit unlogical to register an extension for something that is not registered.
---------------------------------------------------------------------------
by henrikbjorn at 2012-08-22T14:39:57Z
Okay. That wasn't what i got from reading the comment :)
---------------------------------------------------------------------------
by bschussek at 2012-08-22T14:44:27Z
@stof Updated.
Commits
-------
bca68ca Fixed a typo
Discussion
----------
Fixed a typo
The CSRF error message won't be translated due to this typo even if the translator is enabled.
Commits
-------
5ad75c7 updated method name in a comment
Discussion
----------
updated method name in a comment
---------------------------------------------------------------------------
by travisbot at 2012-08-07T14:35:39Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2057604) (merged 5ad75c71 into b91a4a83).
Commits
-------
fb002d8 [Form] Fixed variable passing from outer to inner blocks of the same FormView instance
Discussion
----------
[Form] Fixed variable passing from outer to inner blocks of the same FormView instance
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #5029
Todo: -
This PR fixes two bugs.
The first bug is described in #5029. The second parameter to the "form_label" function in Twig, if given, always overwrote whatever label was defined previously.
```
{# null would overwrite whatever is currently set #}
form_label(form, null, { ... })
```
The second bug affected passing variables from outer to inner blocks. In the following example, "label_attr" would not be forwarded to the "form_label" function.
```
form_row(form, { "label_attr": { "class": "my_class" }})
```
Both bugs are fixed now.
Commits
-------
0ea3769 Fix not recognized "type" option exception
Discussion
----------
[Form] Fixed not recognized "type" option exception
The exception about not recognized "type" option was raised when "date", "datetime", "time" type was guessed by validator type guesser using the date related constraint.
---------------------------------------------------------------------------
by bschussek at 2012-07-25T11:30:23Z
Thanks! 👍
The exception about not recognized "type" option was raised when "date", "datetime", "time" type was guessed by validator type guesser using the date related constraint.
Commits
-------
dd2aa54 [Form] Disabled manual singulars in PropertyPath until the syntax is finalized
Discussion
----------
[Form] Disabled manual singulars in PropertyPath until the syntax is finalized
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Commits
-------
dc3a680 [Form] Improved FormRenderer API to reduce the size of the function call stack during rendering
Discussion
----------
[Form] Improved FormRenderer API to decrease the function call stack
Bug fix: no
Feature addition: no
Backwards compatibility break: **yes**
Symfony2 tests pass: yes
Fixes the following tickets: #4962, #4973
Todo: -
This PR reduces the function call stack size when rendering by directly calling the methods `renderBlock` and `searchAndRenderBlock` (formerly `renderSection`) and removing the delegating methods `render(Widget|Label|Row|...)`.
It breaks BC in that PHP templates now need to pass the FormView instance to `block` (formerly `renderBlock`). This is necessary, otherwise that function may behave buggy in special circumstances.
Otherwise this PR cleans up API method and parameter names to improve clarity.
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
-------
d4f4038 [Form] Reduced the number of setData() calls by deferring a Form's initialization (+40ms)
Discussion
----------
[Form] Reduced the number of setData() calls
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR decreases the number of expensive `setData()` calls on `Form` instances by deferring the form's initialization with default data to the first call to a `get*Data()` method. If `setData()` is called manually before invoking `get*Data()`, the initialization with the default data will not take place.
Before:
```
$form = new Form($config); // implicit setData($config->getData());
$form->setData($object); // setData() is now called twice
```
After:
```
$form = new Form($config); // no implicit setData()
$form->getData(); // implicit setData($config->getData())
// or
$form = new Form($config);
$form->setData($object);
$form->getData(); // setData() was called only once
```
Commits
-------
6489a65 [Form] Added an exception for invalid type services
Discussion
----------
[Form] Added an exception for invalid type services
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes [](http://travis-ci.org/stof/symfony) (Travis fails randomly for the performance test)
Fixes the following tickets: -
Todo: -
Before the introduction of the FormRegistry, the getName() method was
never used for types registered through the DI container. The
FormRegistry now uses the getName() method and missconfigured services
will trigger a notice.
This was reported in FriendsOfSymfony/FOSCommentBundle#234
Before the introduction of the FormRegistry, the getName() method was
never used for types registered through the DI container. The
FormRegistry now uses the getName() method and missconfigured services
will trigger a notice.
This was reported in FriendsOfSymfony/FOSCommentBundle#234
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
Commits
-------
f71e2a8 [Form] FormBuilder Bug Fix: remove() was not properly removing children
Discussion
----------
[Form] FormBuilder Bug Fix: remove() was not properly removing children
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4803
License of the code: MIT
FormBuilder initially sets unresolved children as NULL, until resolved.
If FormBuilder::remove() is called before that child is resolved, the
if statement turns false, because isset(null) is false, when it should
be true. Instead, we should check to see if the key exists, and if so,
process and unset it.
Closes#4803
---------------------------------------------------------------------------
by bschussek at 2012-07-10T07:41:55Z
Can you please add a test covering this case?
---------------------------------------------------------------------------
by ChrisTickner at 2012-07-10T09:43:07Z
Sure, added a test case. It fails before the patch and passes after.
---------------------------------------------------------------------------
by bschussek at 2012-07-10T09:47:06Z
Thanks. Can you please add a comment to the test with the URL of this PR? Also, please squash your commits into one when your done.
---------------------------------------------------------------------------
by ChrisTickner at 2012-07-10T10:02:16Z
Oops, I deleted the remote branch and re-pushed without realizing we'd lose some history on this PR page. Live and learn I suppose.
---------------------------------------------------------------------------
by bschussek at 2012-07-10T10:18:20Z
Thanks!
FormBuilder initially sets unresolved children as NULL, until resolved.
If FormBuilder::remove() is called before that child is resolved, the
if statement turns false, because isset(null) is false, when it should
be true. Instead, we should check to see if the key exists, and if so,
process and unset it.
Closes#4803
Commits
-------
6ad4018 [Form] Also display the hint about adder/remover on invalid property access
Discussion
----------
[Form] Also display the hint about adder/remover on invalid property access
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
This PR follows up #4777. In this case the hint about adders and removers is also added when a property is found, but is not public, a common case.
Commits
-------
9c94b48 [Form] Fixed the "data" option to supersede default data set in the model
Discussion
----------
[Form] Fixed the "data" option to supersede default data set in the model
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3899
Todo: -
Commits
-------
7727de7 [Form] Deprecated Form::bindRequest() and replaced it by a PRE_BIND listener
Discussion
----------
[Form] Deprecated Form::bindRequest() and replaced it by a PRE_BIND listener
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Instead of `bindRequest`, you should now simply call `bind`:
Before:
```
$form->bindRequest($request);
```
After:
```
$form->bind($request);
```
Commits
-------
eba7dfe Revert "[Form] added a circular reference safeguard for form type"
Discussion
----------
Revert "[Form] added a circular reference safeguard for form type"
This reverts commit ea93e4cafa.
Conflicts:
src/Symfony/Component/Form/FormBuilder.php
src/Symfony/Component/Form/FormFactory.php
Commits
-------
df5bb4a [Form] Unified rendering of errors for nested elements
Discussion
----------
[Form] Unified rendering of errors for nested elements
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes?
Symfony2 tests pass: yes
Fixes the following tickets: #4615
Todo: -
Commits
-------
1345360 [Form] Fixed PropertyPath handling of offsetGet() that returns a constant value
6e1462e [Form] Fixed PropertyPath handling of __get() method that returns a constant
Discussion
----------
[Form] Fixed "Indirect modification.." exceptions in PropertyPath
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4450, #4535?, #4612
Todo: -
Commits
-------
040ba8f [Form] Fixed: ChoiceType omits the "empty_value" option if the choices contain an empty element
Discussion
----------
[Form] Fixed: ChoiceType omits the "empty_value" option if the choices contain an empty element
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3854, #3864
Todo: -
Commits
-------
6d94f3e Ensure there is a session before getting the session id
Discussion
----------
[Form] Ensure there is a session before getting the session id
Solves "The CSRF token is invalid. Please try to resubmit the form" error when a form is generated before the session is started.
---------------------------------------------------------------------------
by fabpot at 2012-07-09T10:23:32Z
Adding a CSRF token only makes sense if you are on a page with a "user". If not (and if you don't use HTTP auth or whatever), then there is no need for a CSRF token.
---------------------------------------------------------------------------
by frosas at 2012-07-09T14:42:40Z
This PR doesn't change any logic on whether a CSRF token is added or not, it just fixes a bug when a token is requested.
Commits
-------
1fa22d9 [Form] Output a more usable error when PropertyPath has tried to find adders and getters, but failed to find them
Discussion
----------
[Form] Output a more usable error when PropertyPath has tried to find ad...
...ders and getters, but failed to find them
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
I've refactored the writeProperty method of propertypath in order to supply a better error message when writing has failed.
The writeProperty method itself now finds singulars (if a singular was not passed) for the private findAdderAndRemover method which allowed for some duplicate code to be removed and since the writeProperty now holds this data, it can provide a more verbose exception message.
---------------------------------------------------------------------------
by bschussek at 2012-07-09T13:54:35Z
Apart from the typo this PR looks good.
---------------------------------------------------------------------------
by Burgov at 2012-07-09T14:01:04Z
fixed&squashed
Commits
-------
d6e1f39 [Form] Fixed FormBuilder to maintain order of its children
Discussion
----------
[Form] Fixed FormBuilder to maintain order of its children
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4693
Todo: -
Commits
-------
6f9eda9 [Form][Validator] Fixed generation of HTML5 pattern attribute based on Assert\Regex to remove delimiters.
Discussion
----------
[Form][Validator] Fixed generation of HTML5 pattern attribute based on Assert\Regex by removing delimiters or using a new option: htmlPattern.
Hopefully, this time is the good one…
* Fixes: [#3766, #4077, #4513, #4520, #4521]
* Bug fix: yes
* Feature addition: yes
* BC break: no
* Symfony2 tests pass: yes
In Issue #3766, it was asked that Assert\Regex generates HTML5 pattern attribute.
It was done in PR #4077, but the generated Regex is in delimited format which is not supported by HTML5.
Hence, `/[a-z]+/` would be converted to `[a-z]+`.
If flags are specified like in `/[a-z]+/i`, it cannot be converted and pattern validation will be disabled client-side. If is however now possible, using a new option, `htmlPattern`, to specify the pattern you want to be used.
Example:
```php
<?php
/**
* @Assert\Regex(pattern="/^[0-9]+[a-z]*$/i", htmlPattern="^[0-9]+[a-zA-Z]*$")
*/
private $civic_number;
```
**Note**: [Documentation](http://symfony.com/doc/current/reference/constraints/Regex.html) should be updated accordingly.
---------------------------------------------------------------------------
by lavoiesl at 2012-06-08T15:45:17Z
God, I just found out you can "add more commits to this pull request by pushing to the master branch on lavoiesl/symfony"…
---------------------------------------------------------------------------
by travisbot at 2012-06-08T15:50:31Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1568634) (merged 2d767b41 into b84b46ba).
---------------------------------------------------------------------------
by petajaros at 2012-07-04T14:23:16Z
Anything new about this issue?
---------------------------------------------------------------------------
by lavoiesl at 2012-07-04T16:25:43Z
Alright, tests are passing using `phpunit -c phpunit.xml.dist --filter 'RegexValidatorTest'`. @travisbot reports errors because he can’t even start the tests due to dependencies, which is not related
---------------------------------------------------------------------------
by vicb at 2012-07-04T16:31:13Z
It should be ready to merge when you have taken the last comments into account. thanks.
---------------------------------------------------------------------------
by lavoiesl at 2012-07-04T16:39:05Z
So it seems this PR will finally pass, thanks a lot.
---------------------------------------------------------------------------
by vicb at 2012-07-04T17:03:35Z
Thank you for this PR and the changes.
---------------------------------------------------------------------------
by fabpot at 2012-07-04T17:10:20Z
@lavoiesl Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by lavoiesl at 2012-07-04T17:25:18Z
There. I also left trace of some commits I did.
Thanks
[Validator] Added delimiter escaping to Validator\Constraints\Regex::getNonDelimitedPattern
[Form][Validator] Added htmlPattern option for Regex Validation.
[Validator] Fixed Validator\Constraints\Regex::getNonDelimitedPattern variable declarations
[Validator] Fixed tests for Regex htmlPattern option (instead of html_pattern)
[Validation] tweaked generation of pattern to include .* when not anchors are present. Also removed the exception and made getNonDelimitedPattern private
Commits
-------
c1e4166 moved create of default form label to view layer
Discussion
----------
move create of default form label to view layer
A small optimization if you provide custom labels in the view layer (i.e. `{{ form_label(form.name, 'Your name') }}`
```
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: ~
Todo: ~
License of the code: MIT
Documentation PR: ~
```
---------------------------------------------------------------------------
by travisbot at 2012-06-24T14:45:17Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1694310) (merged 37f0b774 into 0d4b02e4).
---------------------------------------------------------------------------
by travisbot at 2012-06-24T15:03:44Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1694418) (merged c1e4166e into 0d4b02e4).
Commits
-------
6b5b625 [Form] added FormBuilderInterface in Tests namespace, so as to enable easy mocking
Discussion
----------
[Form] added FormBuilderInterface in Tests namespace, so as to enable ea...
...sy mocking
Adding a ``FormBuilderInterface`` in the ``Tests`` namespace, along same lines as ``FormInterface`` already there, for the purposes of being able to mock it straightforwardly (as ``FormBuilderInterface`` extends ``\Traversable``, and therefore creating a mock in PHPUnit causes a fatal error that the mock ``must implement interface Traversable as part of either Iterator or IteratorAggregate``). Currently in the tests a ``FormBuilder`` object is used with a mock event dispatcher and form factory passed into the constructor, but this is long-winded to have to do in tests for code outside the framework.
---------------------------------------------------------------------------
by travisbot at 2012-06-13T22:03:12Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1613957) (merged 6b5b625a into c07e9163).
---------------------------------------------------------------------------
by bschussek at 2012-06-14T07:22:33Z
👍
This issue camelizes the 'add' and 'remove' methods,
as it is already done with the 'set' method.
This fixes a problem with properties like 'custom_messages',
where the 'add' and 'remove' methods are 'addCustom_message'
and 'removeCustom_message' instead of 'addCustomMessage'
and 'removeCustomMessage'.
Commits
-------
bfe5e58 [Form] fixed typo in docblock
Discussion
----------
[Form] fixed typo in docblock
---------------------------------------------------------------------------
by travisbot at 2012-06-15T20:03:08Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1630865) (merged bfe5e585 into f881d282).
Commits
-------
b5cf337 [Form] Enhanced the form error message
Discussion
----------
[Form] Enhanced the form error message
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
The error message on type mismatch is a bit obscure:
The form's view data is expected to be an instance of class Samson\Bundle\TRSBundle\Entity\Labour, but has the type object. You can avoid this error by setting the "data_class" option to null or by adding a view transformer that transforms object to Samson\Bundle\TRSBundle\Entity\Labour.
This commit changes it to:
The form's view data is expected to be an instance of class Samson\Bundle\TRSBundle\Entity\Labour, but is an instance of class Closure. You can avoid this error by setting the "data_class" option to null or by adding a view transformer that transforms an instance of Closure to an instance of class Samson\Bundle\TRSBundle\Entity\Labour.
---------------------------------------------------------------------------
by travisbot at 2012-06-12T14:04:08Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1601478) (merged 70a15df6 into 77839690).
---------------------------------------------------------------------------
by travisbot at 2012-06-12T14:06:31Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1601507) (merged 12ec4dbd into 77839690).
---------------------------------------------------------------------------
by travisbot at 2012-06-12T14:13:09Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1601517) (merged b5cf337c into 77839690).
---------------------------------------------------------------------------
by bschussek at 2012-06-12T18:21:31Z
👍 Thanks!
The error message on type mismatch is a bit obscure:
The form's view data is expected to be an instance of class Samson\Bundle\TRSBundle\Entity\Labour, but has the type object. You can avoid this error by setting the "data_class" option to null or by adding a view transformer that transforms object to Samson\Bundle\TRSBundle\Entity\Labour.
This commit changes it to:
The form's view data is expected to be an instance of class Samson\Bundle\TRSBundle\Entity\Labour, but is an instance of Closure. You can avoid this error by setting the "data_class" option to null or by adding a view transformer that transforms an instance of Closure to an instance of Samson\Bundle\TRSBundle\Entity\Labour.
Commits
-------
a30f4a0 [Form] cleanup
Discussion
----------
[Form] cleanup
---------------------------------------------------------------------------
by travisbot at 2012-05-27T19:47:21Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1450050) (merged 09574f4b into adf07f1e).
---------------------------------------------------------------------------
by travisbot at 2012-05-27T19:57:42Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1450149) (merged a8c63d72 into adf07f1e).
---------------------------------------------------------------------------
by vicb at 2012-05-27T20:00:13Z
thanks a bunch @travisbot !
---------------------------------------------------------------------------
by travisbot at 2012-05-28T06:52:52Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1453555) (merged a30f4a03 into adf07f1e).
---------------------------------------------------------------------------
by bschussek at 2012-05-28T09:20:05Z
Thank you Victor! 👍
Commits
-------
59c4f55 a few minor changes
Discussion
----------
a few minor changes / cleanup
---------------------------------------------------------------------------
by travisbot at 2012-05-27T07:58:52Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1446431) (merged bb7ae326 into 9e951991).
