-
Notifications
You must be signed in to change notification settings - Fork 702
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
[Meta] Impact of SensioFrameworkExtraBundle deprecation #2354
Comments
Seems like SensioFrameworkExtraBundle has been deprecated (sensiolabs/SensioFrameworkExtraBundle#783). |
The Symfony PR for the request body converter didn't land in 6.2, and it's hardcoded to the Symfony serializer component anyway, so it wouldn't be a full replacement for the converter here (which can use the abstraction layer to switch between the Symfony or JMS serializer as appropriate). Also, the HttpKernel's argument value resolvers aren't allowed to return more than one value except for a variadic argument, so the feature provided here where the deserialized model can be automatically validated and the resulting violation list passed through to the controller won't be available. With that said... When updating one of my apps to 6.2, I made a pretty simplified version of the converter already in place for this bundle:
So if you intend to use it on something older or support other functionality, keep in mind you'll have to make changes:
And the accompanying Attribute class: <?php declare(strict_types=1);
namespace App\Http\Attribute;
#[\Attribute(\Attribute::TARGET_PARAMETER)]
final class RequestBody
{
public function __construct(
public readonly array $attributes = [],
public readonly ?string $version = null,
public readonly ?array $groups = null,
public readonly ?bool $isMaxDepthEnabled = null,
public readonly ?bool $serializeNull = null,
) {
}
} I'm now just handling validation inside my controllers instead of trying to rely on request state or prioritizing resolvers correctly or any of that fancy stuff. ==== I've personally never used the annotations/attributes that SensioFrameworkExtraBundle provided for all the other features, so I honestly have no idea how to gauge the effort to migrate the |
I have just moved a project to 6.2 and the default I'd guess even with the replacement of the |
The |
OK, so I just found a conflict with the default behaviour of Symfony 6.2? I have the exact configuration described by request_body_converter_listener.rst but have needed to add Perhaps it's not directly related to the deprecation of |
The two systems have some functional differences (when they're fired in the request cycle, the param converters by default store all of their resolved values to the request's attributes bag but I don't think the value resolvers do the same), so it's not a straightforward one-for-one swap. The notes on that doc page are really only going to work if you're only using the param converters from |
Thanks for the tips. My issue was solved purely by disabling the |
Due to the hard dependency between I understand, from this discussion, that it's not possible to disable I managed to short-circuit
And, in
Could this results in loss of functionality with FOSRestBundle? |
There are ways to disable the param converter integrations, but turning those off does disable functionality (if you're on Symony 6.2, the only thing you're missing is the request body conversion, which you can restore in a few ways). If you're aiming to keep the Sensio bundle installed but disable features that are now part of the core framework, you've got two options (depending on your needs) for the param converters specifically: # Fully disable the param converter integration
sensio_framework_extra:
request:
converters: false
# Disables the Doctrine ORM param converter only
sensio_framework_extra:
request:
disable:
- 'doctrine.orm' If you're trying to remove the Sensio bundle in full (which you should be able to do, there aren't many actively maintained bundles which have a hard requirement to the Sensio bundle; even this one only has it in |
@mbabker thanks for the quick answer. I'm indeed trying to remove sensio's extra bundle.
But |
If you're using that feature, you need the Sensio bundle. That functionality hasn't been updated yet (and as my original post says, I don't use that particular feature so I'm not in a good spot to gauge the effort involved in fixing that). |
Reading https://symfony.com/blog/new-in-symfony-6-3-mapping-request-data-to-typed-objects this morning got me thinking about this whole migration again. The core framework features are nice, but they hard-couple you to the framework's serializer and I think one of the benefits of this bundle is it lets you work with either the Symfony or JMS serializer, so just using those is out of the question. That gets me thinking about this bundle's features as a whole. Obviously, the That then makes me start thinking about the There is still also the So I guess it's just a matter of figuring out what to migrate forward, how to do it, and what PHP/framework versions need to be supported in the newer code (i.e. Symfony 6.2 deprecates some stuff in the controller argument resolvers so only supporting 6.2+ has a simpler implementation than 5.4+). |
I'm trying to follow along but getting a bit lost. Is there some drop in replacement for |
The framework itself uses argument value resolvers, which is the canonical replacement for the SensioFrameworkExtraBundle's param converters. If your question is about replacing the param converter this bundle provides, there isn't one yet. #2398 is a WIP on this, but given the two systems have different behaviors, it isn't a straightforward one-for-one swap. |
Thanks @mbabker, I'll check out the issue/PR you linked on the WIP. That is, unfortunately, a blocker for me :( |
since version 3.7 the view annotation is optional thanks to https://github.com/FriendsOfSymfony/FOSRestBundle/pull/2401/files in our project we were able to finally uninstall the deprecated sensio bundle |
We are thinking of using newer Symfony core attributes like But then Sensio's Was there a way around this already or do we need to use either one or the other in the current state of things? Sorry if I missed this, I did some research and digged into the code but didn't get not much smarter yet. |
You can disable converters in the sensio_framework_extra:
request:
disable:
# The name comes from the "converter" attribute for the "request.param_converter" tag, i.e. <tag name="request.param_converter" converter="doctrine.orm" />
- 'datetime'
- 'doctrine.orm' |
thank you @mbabker! I appreciate the fast response. In my case apparently it was even simpler and I can just disable |
In symfony/symfony#44705 it looks like there's a strong consensus for deprecating SensioFrameworkExtraBundle (which, IMO, makes sense; everything that bundle provides can be done with a core install these days, the only features it really provides are some annotations that affect the DX of how controllers are written).
If that bundle is deprecated, it does have some impact on features here, including:
#[MapRequestPayload]
and#[MapQueryString]
to map Request input to typed objects symfony/symfony#49138@View
annotation (which is an extension of the@Template
annotation)The param converter can already be addressed by creating an argument resolver with an attribute for the extra configuration (IMO, with Symfony 6 being PHP 8+ and 7.4 having entered security only support, I don't think this new class would need to support annotations).
The
@View
annotation would either need to be decoupled from the@Template
annotation, rewritten to use whatever replacement is introduced into the framework itself (if one is added), or deprecated in full.The text was updated successfully, but these errors were encountered: