Skip to content

[Form][OptionResolver] Support of OptionResolver 2.6 API in AbstractType #12782

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
peterrehm opened this issue Nov 30, 2014 · 4 comments
Closed

[Form][OptionResolver] Support of OptionResolver 2.6 API in AbstractType #12782

peterrehm opened this issue Nov 30, 2014 · 4 comments
Labels
Form OptionsResolver

Comments

@peterrehm
Copy link
Contributor

I have just tried the upgrade of an application to 2.6 and followed the upgrade document.

I noticed that there were major changes in the OptionResolver component with the depreciation
of the OptionResolverInterface. This was well documented in the OptionResolver documentation.

However it looks like there is no upgrade path for form classes extending the AbstractType since
the interface requires the OptionResolverInterface. I think we should offer an upgrade path to get
rid of the depreciation warnings. Will the AbstractType setDefaultOptions be changed in 3.0 or will
there be a new method?

@webmozart Or am I missing something?

Related symfony/symfony-docs#4159 #12156
@xabbuh xabbuh mentioned this issue Dec 1, 2014
Closed
@gondo
Copy link
Contributor

gondo commented Dec 1, 2014

exactly my thoughts, what is the recommended solution for this?

@peterrehm peterrehm mentioned this issue Dec 3, 2014
Closed
@wouterj
Copy link
Member

wouterj commented Dec 7, 2014

Imo, there are 2 things in this subject which should be changed in the type interface:

  1. With the addition of the OptionsResolver component, the setDefaultOptions method is wrong since it does a lot more
  2. With the api changes in 2.6, it should typehint for OptionsResolver instead of the interface.

I think we can combine these 2 by deprecating setDefaultOptions and introducing configureOptions, which has a correct typehint.

@peterrehm
Copy link
Contributor Author

I am fine with this, sounds reasonable. I will have a look into this.

@peterrehm peterrehm mentioned this issue Dec 8, 2014
Merged
@peterrehm
Copy link
Contributor Author

I just submitted an PR with some initial work on this.

fabpot added a commit that referenced this issue Jan 18, 2015
@fabpot
feature #12891 [Form] Deprecated setDefaultOptions() in favor of conf…
fef2bd4 
…igureOptions() (peterrehm)

This PR was merged into the 2.7 branch.

Discussion
----------

[Form] Deprecated setDefaultOptions() in favor of configureOptions()

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   |
| Fixed tickets | #12782
| License       | MIT
| Doc PR        | symfony/symfony-docs#4786

This tries to provide a compatible API with the depreciation of the OptionResolverInterface. I would like to have this in 2.6.2 but I think that might not be possible? To me I think we should always provide an API where you do not need to use deprecated classes.

Also can you think of any way to trigger errors on the use of the deprecated setDefaultOptions() method? Since it is usually overwritten without calling the parent class this might be tricky. Maybe only in the resolver if we can check if actual options has been resolved in a call to setDefaultOptions.

Commits
-------

3d43cae Deprecated setDefaultOptions() in favor of configureOptions()
@fabpot fabpot closed this as completed Jan 18, 2015
@jakzal jakzal mentioned this issue Jun 2, 2015
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Form OptionsResolver
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@fabpot @gondo @wouterj @peterrehm