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

Add a single-file variant of FileField and get rid of ternary logic for value presence in multi-file variant #104

Open
mdindoffer opened this issue Sep 18, 2023 · 0 comments

Comments

@mdindoffer
Copy link
Contributor

The FileField is actually a Field for a list of files.

This is first of all confusing, since there's no indication of the plurality in the name.
Second, consumers always have to wrap values in a single-valued list when setting the value.

However, when trying to work with this field in a single-file mode, it gets even worse due to a ternary value state instead of simple null/notnull:

  1. Either the value is null, so calling field.getValue() will return a null pointer
  2. Or there is a file present (uploaded, or just loaded), and the field.getValue() will return a single-valued List, so you always have to call field.getValue().get(0) to get to the actual contents.
  3. Or there's sort of a grey zone, when client uploads a file to the FileField, but then removes it. This leads to a situation where the field.getValue() will return a List, not null, but the List is empty. In turn, one must always check both for nullity of the value and the emptyness of the List.

It would be great if we had two variants of the FileField:

  1. One for singular files, so not inheriting from AbstractFileField<List<RECORD>>
  2. One keeping the multi-file behaviour, but sticking to a two state logic (null, notnull) in all interaction scenarios.
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

No branches or pull requests

1 participant