Skip to content
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

Allow to decorate the UploaderHelper #1288

Merged
merged 5 commits into from
May 23, 2022
Merged

Allow to decorate the UploaderHelper #1288

merged 5 commits into from
May 23, 2022

Conversation

VincentLanglet
Copy link
Contributor

Hi @garak.

I recently tried the 1.19 version and got an issue.

Since the UploaderHelper is/will be final, I cannot extends it.
But since this class is required (and not an interface) in the construct of the UploaderExtension, I cannot use decoration either.

This PR solve this issue.

@garak
Copy link
Collaborator

garak commented May 9, 2022

I don't think we'll need that in the next major version.
UploaderHelper is just a legacy class from the time when we supported non-twig templates, probably it will be removed. Its logic will be moved directly into UploaderExtension.

@garak
Copy link
Collaborator

garak commented May 9, 2022

I have to correct myself: UploaderHelper can be directly used, indeed.

Anyway, I think that we can delay the move of adding a new interface to the next major version.

@VincentLanglet
Copy link
Contributor Author

Anyway, I think that we can delay the move of adding a new interface to the next major version.

Why should we delay this ?

Adding the interface in the 1.x version, allows people to solve deprecation/message about the fact the UploaderHelper is final. Currently I have two solutions

  • Sticking with 1.18 version
  • Updating to 1.19 version and getting static-analysis errors about the fact I extend a @final method.

With the interface I could use decoration, solve my issue and update the library.

It seems better to give a migration path rather than having to solve all the BC break in the next major.

@garak
Copy link
Collaborator

garak commented May 9, 2022

The problem is that we would change the signature of the UploaderExtension constructor, and this can break if a user extended it.

@VincentLanglet
Copy link
Contributor Author

The problem is that we would change the signature of the UploaderExtension constructor, and this can break if a user extended it.

Changing UploaderHelper to UploaderHelperInterface is not a BC-break since UploaderHelper implements UploaderHelperInterface.

Prior to this, if you pass UploaderHelper to the constructor it will still works.
And if you pass CustomUploaderHelper extends UploaderHelper it will still works since it implements the UploaderHelperInterface interface thanks to UploaderHelper.

@garak
Copy link
Collaborator

garak commented May 9, 2022

Changing UploaderHelper to UploaderHelperInterface is not a BC-break since UploaderHelper implements UploaderHelperInterface.

That's a good point.
So, I guess you only need to make tests passing.

@VincentLanglet
Copy link
Contributor Author

Changing UploaderHelper to UploaderHelperInterface is not a BC-break since UploaderHelper implements UploaderHelperInterface.

That's a good point. So, I guess you only need to make tests passing.

Tests are fixed.

@VincentLanglet
Copy link
Contributor Author

@garak I tried to add some deprecations. Tell me if it's ok for you.

@@ -41,6 +41,16 @@ public function getFunctions(): array
*/
public function asset($object, ?string $fieldName = null, ?string $className = null): ?string
{
if (!\is_object($object)) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already deprecated in the helper. If we keep it here too, user will get a duplicate deprecation warning, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only if you don't use a custom UploaderHelper.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to avoid duplicate deprecation, I can add a check !$this->uploaderHelper instanceof UploadHelper.
WDYT ?

@VincentLanglet
Copy link
Contributor Author

@garak I avoid the duplicate deprecations now

@garak garak merged commit cbf3d2c into dustin10:master May 23, 2022
@garak
Copy link
Collaborator

garak commented May 23, 2022

Thank you @VincentLanglet

@VincentLanglet
Copy link
Contributor Author

Thank you @VincentLanglet

You're welcome ; do you have time for a release ? :)

@garak
Copy link
Collaborator

garak commented May 23, 2022

As soon as we sort up #1273

@VincentLanglet
Copy link
Contributor Author

Now #1273 is solved, do you have time to create a new release @garak ?

@VincentLanglet VincentLanglet deleted the helperInterface branch July 13, 2022 08:38
@garak
Copy link
Collaborator

garak commented Jul 18, 2022

Here you are https://github.com/dustin10/VichUploaderBundle/releases/tag/1.20.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants