Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Followup from #2169983: Move type-specific logic from ListItemBase to the appropriate subclass :
validateAllowedValue()
validates that the input for the "allowed values" settings UI is valid for the List* field type (int, float, text...)
It would be best as a single generic implementation in ListItemBase
, that validates the value against the TypedData definition of the 'value' property defined in propertyDefinitions(),
which already specifies all the constraints we need and is able to check them.
Also this could help to decouple BooleanItem
to Core
Comment | File | Size | Author |
---|---|---|---|
#7 | 2226071-2-7-interdiff.txt | 2.45 KB | e0ipso |
#7 | list-validate-alowed-value-2226071-7.patch | 8.04 KB | e0ipso |
Comments
Comment #1
andypostComment #2
e0ipsoMoves
validateAllowedValue()
upstream toListItemBase
and leveragesTypedData
validation capabilities to validate values and generate error messages.Comment #3
e0ipsoComment #4
andypostwas split in #2169983: Move type-specific logic from ListItemBase to the appropriate subclass
For purpose to decouple boolean item in #2226063: Merge ListBooleanItem from options module into BooleanItem
same applies here, no reason to implement new protected method
Comment #5
andypostComment #7
e0ipsoThis should fix the broken tests, but it doesn't implement @andypost's feedback. I'm still unclear about the feedback in #4, I'll try to find @andypost in IRC.
Comment #8
e0ipsoComment #9
fagoIt shouldn't be necessary to move the value definition to a separate method just for validation. Given the main property name being "value" it should work fine just by having a regular property constraint, i.e. see how setPropertyConstraint() on FieldDefinition configures the constraints.