You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Either the value is null, so calling field.getValue() will return a null pointer
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.
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:
One for singular files, so not inheriting from AbstractFileField<List<RECORD>>
One keeping the multi-file behaviour, but sticking to a two state logic (null, notnull) in all interaction scenarios.
The text was updated successfully, but these errors were encountered:
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:
value
isnull
, so callingfield.getValue()
will return a null pointerfield.getValue()
will return a single-valuedList
, so you always have to callfield.getValue().get(0)
to get to the actual contents.FileField
, but then removes it. This leads to a situation where thefield.getValue()
will return aList
, notnull
, but theList
is empty. In turn, one must always check both for nullity of the value and the emptyness of theList
.It would be great if we had two variants of the
FileField
:AbstractFileField<List<RECORD>>
The text was updated successfully, but these errors were encountered: