-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[RFC] Abandon FrameworkExtraBundle #44705
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
Comments
I agree. |
I don't get the logic. There's a set of optional features in a bundle that is not well maintained. The solution should be maintaining that bundle, not putting optional features in the core. I think a strong point of Symfony is having a slim base and modularity, I hope it's not going to transform in a copy of Laravel. |
Let's not act as if moving 3 annotations as native PHP attributes to core will upset anyone please. That being said, "the solution should be maintaining the bundle" is nicely said but not the practice. Apparently nobody is interest in maintaining the bundle (for years now). I'm all +1 for the latter. |
@garak generally speaking I agree with you ... but in this particular case, I think the bundle was "wrong" since day one. I mean, these were so useful and common features that I never felt them as "extra features". In my opinion, they should've been "core/built-in features" since day one. |
These feature were in a bundle as annotations in phpdocs were controversial back then. Now that we have native annotations, it makes sense to move them to core. Add simple as that. |
I agree with this as well. @derrabus will you do/coordinate the work? |
As several features have not been migrated yet to the core, we cannot abandon the bundle yet (we probably cannot abandon it fully before the end of the 5.4 LTS, as the 5.4 branch won't have replacements). However, I'm also in favor of bringing the remaining features to the core to abandon the bundle in the future |
This PR was merged into the 6.1 branch. Discussion ---------- [HttpKernel] Add DateTimeValueResolver | Q | A | ------------- | --- | Branch? | 6.1 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | #44705 | License | MIT | Doc PR | symfony/symfony-docs#16562 This PR replaces the [DateTimeParamConverter](https://github.com/sensiolabs/SensioFrameworkExtraBundle/blob/master/src/Request/ParamConverter/DateTimeParamConverter.php) from the SensioFrameworkExtraBundle with a value resolver in the Symfony Core. Note that the behavior of the resolver is enabled by default when using the Symfony framework. Commits ------- dcc1228 [HttpKernel] Add DateTimeValueResolver
Thank you for this suggestion. |
@carsonbot keep this opened. The work is in progress in various places |
… handle attributes on controllers (nicolas-grekas) This PR was squashed before being merged into the 6.2 branch. Discussion ---------- [HttpKernel] Add `ControllerEvent::getAttributes()` to handle attributes on controllers | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - Replacing #45457. Paving the way toward #44705 Commits ------- 0f2293c [HttpKernel] Add `ControllerEvent::getAttributes()` to handle attributes on controllers
Help wanted (see #45415):
|
This PR was merged into the 6.2 branch. Discussion ---------- [Security] Add `#[IsGranted()]` | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | Part of #44705 | License | MIT | Doc PR | - Extracted from #45415 (and modernized a lot). I did not implement the proposals from Stof to keep this first iteration simple. I'd appreciate help to improve the attribute in a follow up PR 🙏 Commits ------- bf8d75e [Security] Add `#[IsGranted()]`
…nder arrays returned by controllers (nicolas-grekas) This PR was merged into the 6.2 branch. Discussion ---------- [TwigBridge] Add `#[Template()]` to describe how to render arrays returned by controllers | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | Part of #44705 | License | MIT | Doc PR | - Extracted from #45415 (and modernized a lot). Unlike the``@Template`` annotation, this attribute mandates a template name as argument. This removes the need for any template-guesser logic, making things explicit. Using the attribute also turns `FormInterface` instances into `FormView`, adjusting the status code to 422 when a non-valid form is found in the parameters, similarly to what `AbstractController::render()` does. Commits ------- c252606 [TwigBridge] Add `#[Template()]` to describe how to render arrays returned by controllers
We don't need this one, do we? |
indeed, I don't think we need it |
…HTTP cache headers on controllers (nicolas-grekas) This PR was merged into the 6.2 branch. Discussion ---------- [HttpKernel] Add `#[Cache()]` to describe the default HTTP cache headers on controllers | Q | A | ------------- | --- | Branch? | 6.2 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | Part of #44705 | License | MIT | Doc PR | - Extracted from #45415 (and modernized a lot). I'd appreciate any help for porting the other attributes following this leading PR 🙏 Commits ------- acd4fa7 [HttpKernel] Add `#[Cache]` to describe the default HTTP cache headers on controllers
The main features have been migrated to core. Let's iterate and deprecate FrameworkExtraBundle :) |
Well, let's wait for the release of the core feature first before deprecating FrameworkExtraBundle |
@stof I know this is an old closed issue but I have a relevant question. I am on the latest 5.4.x. I just migrated from annotations to attributes. Everything is working great. grep is returning no instances of And yet... when I remove the SensioFrameworkExtraBundle entry from It looks like |
Please use our discussions board for support questions: https://github.com/symfony/symfony/discussions |
Description
Since Symfony 2
sensio/framework-extra-bundle
is the solution for adding annotation-magic to the application. Since then, some functionality has been moved to the core (e.g. annotation-based routing) and other functionality has been obsoleted by a core feature (param converters Vs. argument value providers).FrameworkExtraBundle feels like a core-bundle but it's not as well maintained as we would expect a core bundle to be.
I think, it would be a good idea to review the feature set of the bundle and move commonly used functionality to the monorepo. Speaking for myself, that would be the security annotations like
IsGranted
as well as the Doctrine entity param converter (see #43854).What do you think?
Example
No response
The text was updated successfully, but these errors were encountered: