8000 test for ensuring creating form returns data of type specified in data_c... by cordoval · Pull Request #3383 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

test for ensuring creating form returns data of type specified in data_c... #3383

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

test for ensuring creating form returns data of type specified in data_c... #3383

wants to merge 1 commit into from

Conversation

cordoval
Copy link
Contributor

...lass

~ phpunit tests/Symfony/Tests/Component/Form/FormFactoryTest.php 
PHPUnit 3.6.4 by Sebastian Bergmann.

Configuration read from /home/cordoval/sites-2/forum/vendor/symfony/phpunit.xml.dist

..........................F.

Time: 0 seconds, Memory: 11.25Mb

There was 1 failure:

1) Symfony\Tests\Component\Form\FormFactoryTest::testNullObjectWithCustomTypeReturnsCorrectObjectType
Failing in returning object of type specified in data_class when creating with empty data
Failed asserting that false is true.

/home/cordoval/sites-2/forum/vendor/symfony/tests/Symfony/Tests/Component/Form/FormFactoryTest.php:531

FAILURES!
Tests: 28, Assertions: 57, Failures: 1.

@stof
Copy link
Member
stof commented Feb 16, 2012

This is expected. You return null for the parent, meaning that your type does not inherit the behavior implemented in FieldType. And so you don't get the logic implemented to use data_class for the empty data

@cordoval
Copy link
Contributor Author

oh but that empty_data is new right? that is a BC

On Thu, Feb 16, 2012 at 3:57 PM, Christophe Coevoet <
reply@reply.github.com

wrote:

This is expected. You return null for the parent, meaning that your
type does not inherit the behavior implemented in FieldType. And so you
don't get the logic implemented to use data_class for the empty data

Reply to this email directly or view it on GitHub:
#3383 (comment)

@cordoval
Copy link
Contributor Author

@stof If I comment the method getParent I get

Symfony\Component\Form\Exception\FormException: Could not load type "form"

@stof
Copy link
Member
stof commented Feb 16, 2012

@cordoval you need to register the other form types in the FormFactory to be able to use them.

And empty_data is not new. And the fact that you don't inherit the behavior from FieldType when you don't mark it as parent is not new either (you don't inherit the rendering either btw)

@web-dev
Copy link
web-dev commented Feb 17, 2012

I believe this is a BC break - I had some code using the collection field that was working fine in SF 2.0, when I ported to SF 2.1 it broke.

I resolved the issue by setting the empty_data element of the default options array in my form type.

The current documentation still states that it is correct to use the data_class element in your form type: http://symfony.com/doc/current/book/forms.html

@stof
Copy link
Member
stof commented Feb 17, 2012

@web-dev there is indeed an issue in the current refactoring (I opened a tocket for it). But this test is not the right one to demonstrate it as the case presented in the test is expected to fail for the empty data as it simply does not have a way to trigger the logic of the FieldType

@fabpot
Copy link
Member
fabpot commented Feb 17, 2012

Can we close this PR then?

@merk
Copy link
Contributor
merk commented Feb 19, 2012

It appears there is an issue here, my custom collection based FormTypes are no longer working (returning arrays instead of the class specified by data_class that is defined in the getDefaultOptions() array).

@stof what issue are you referring to? I cant seem to find it.

@stof
Copy link
Member
stof commented Feb 19, 2012

@merk see #3354

@merk
Copy link
Contributor
merk commented Feb 19, 2012

@stof's issue overlaps with my problem so this can be closed (afaik)

@stof stof closed this Feb 19, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@cordoval @stof @web-dev @fabpot @merk
0