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

Refactor RenameUpload filter to implement FlterInterface #223

Open
wants to merge 1 commit into
base: 3.0.x
Choose a base branch
from

Conversation

marcelthole
Copy link

Q A
Documentation yes
Bugfix no
BC Break yes
New Feature no
RFC yes
QA no

Description

Move RenameUpload filter also to the implementation via FilterInterface and removed the AbstractFilter

@froschdesign froschdesign added this to the 3.0.0 milestone Jan 9, 2025
* @template TOptions of Options
* @extends AbstractFilter<TOptions>
* @implements FilterInterface<mixed>
* @final
Copy link
Author

Choose a reason for hiding this comment

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

Used this @final instead of making the class final because otherwise we could not overwrite the move_uploaded_file function.

Or do you prefer to pass a dependency via option that could change the behavior via DependencyInjection? And should the option be documented as well?

Copy link
Author

Choose a reason for hiding this comment

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

I added the deprecated aswell for these methods here #224

Copy link
Member

Choose a reason for hiding this comment

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

We should be able to make this final without any problems… and IMO it should be @implements FilterInterface<string>, and operate on a single upload at a time. If it allows multiple uploads, then we should change that.

&& array_key_exists('name', $value)
) {
/** @var UploadedFile $uploadedFile */
$uploadedFile = $value;
Copy link
Author

Choose a reason for hiding this comment

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

i don't know why psalm will not detect it if i add the @var annotation directly to $value

Copy link
Member

Choose a reason for hiding this comment

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

There's a value object you can use in Filter\File\FileInformation

if (! FileInformation::isPossibleFile($value)) {
    return $value; // not an upload
}

$file = FileInformation::factory($value);

This should also negate the need for the other PSR related deps.

Psalms refusal to accept the forced @var is probably because of the templates

* @psalm-suppress MixedReturnStatement
* @template T
* @param T $value
* @return (T is UploadedFileInterface
Copy link
Author

Choose a reason for hiding this comment

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

sadly i had to duplicate this doctype because otherwise psalm will detect the mixed return type and mark that as an error for all following calls in the Tests. This comes from the FilterInterface @return TFilteredValue|T but i could not define it strict. So i need to use @implements FilterInterface<mixed> in this class and overwrite the return type here manually

* }
* @template TOptions of Options
* @extends RenameUpload<TOptions>
* @psalm-suppress InvalidExtendClass
Copy link
Author

Choose a reason for hiding this comment

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

Expected error because the RenameUpload is marked as @final

@gsteel
Copy link
Member

gsteel commented Jan 10, 2025

@marcelthole I'm not going to review this just yet, because I think that discussion in #222 is relevant here too

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

Successfully merging this pull request may close these issues.

3 participants