-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[FrameworkBundle] Deprecated form types as services #18356
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.
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
[FrameworkBundle] Deprecated form types as services #18356
Conversation
61ca117
to
3389574
Compare
LGTM 👍 |
Should we add a note in the UPGRADE file ? |
@HeahDude I think so. |
3389574
to
e629d91
Compare
@xabbuh Thanks for the review. Done. is the "before/after" really needed? |
After: | ||
|
||
```php | ||
$type = '\Symfony\Component\Form\Extension\Core\Type\TextType': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or something like:
use Symfony\Component\Form\Extension\Core\Type\TextType;
$type = TextType::class;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with it in general but I think it feels redundant in short examples such as here or docblocks and is used as is in the core.
I'm fine either way though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The before and after is not the same thing. And I don't see the point of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tobion agreed, it misses the new
.
Actually we could just remove them, but we have to deprecate them so devs who had the crazy idea to use them as services might be warned to do otherwise.
Telling them to instantiate the class instead can look trivial I agree, but may be needed.
I'm not so sure about both ways.
Waiting for a final call on this, thanks again for the review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would simply list the IDs of the deprecated services. Passing them to the form builder should already produce errors as the builder is expecting a string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right we should above all avoid to add confusion about that.
So actually it does not really miss the new
even if it's not the "same" thing, it is the way to do it now.
I think we should keep it like this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe just be more accurate:
You should use the fully-qualified name instead of a form type
instead of instantiate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we shouldn't even mention that. Let's keep it simple like this:
3.1:
The ... services are deprecated and will be removed in 4.0.
4.0:
The ... services have been removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because all the other stuff about instantiating form type classes etc. is already handled in the upgrade docs for 2.8 and 3.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good 👍
a4f6114
to
ed11b56
Compare
Ok this one might be ready now. |
@@ -24,6 +24,40 @@ FrameworkBundle | |||
|
|||
* As it was never an officially supported feature, the support for absolute | |||
template paths has been deprecated and will be removed in Symfony 4.0. | |||
* The core form types registered as services: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Breaking the sentence in the middle looks weird, what about
The following form types registered as services are deprecated since 3.1 and will be removed in 4.0; use their fully-qualified class name instead:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still not convinced that it is necessary to add the "use their fully-qualified class name instead" part here (passing the form type instance retrieved from the container already doesn't work).
I think writing "The following services are deprecated since 3.1 and will be removed in 4.0:" is sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. I've first went for @xabbuh suggestion but it was to weird to have just the list.
Since this is the upgrade file and might be relevant to ones getting deprecation notices, so a minimum of "what and what to do instead" makes sense IMHO so I used @fabpot's.
It's now accorded to the framework bundle changelog. Final call ?
0f88617
to
02d173c
Compare
@HeahDude In the 4.0 upgrade file the same services should be listed to, but they should there be mentioned as being removed. |
@xabbuh Ok I was not aware of it, thanks! |
02d173c
to
dfe4f53
Compare
Done, feels weird :) |
Thank you @HeahDude. |
…eahDude) This PR was merged into the 3.1-dev branch. Discussion ---------- [FrameworkBundle] Deprecated form types as services | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | ~ | License | MIT | Doc PR | ~ These services are needless in regard of #15079. If they have no dependencies, whatever are the registered extensions, `FormTypeInterface` instances will be autoloaded by their FQCN. Commits ------- dfe4f53 [FrameworkBundle] Deprecated form types as services
These services are needless in regard of #15079.
If they have no dependencies, whatever are the registered extensions,
FormTypeInterface
instances will be autoloaded by their FQCN.