-
Notifications
You must be signed in to change notification settings - Fork 40
Are you planning to remove the NumericRange from BT-36-Lot? I don't see it anymore in the RC-2 for 1.15.
We use this attribute and find it very useful.
All reactions
Dear @JanEmde,
BT-36 is of type duration. SDK-2 changes the way we deal with durations which are in fact a specific type of measure. The problem in EFX-1 is that it would treat any measure field as duration. But that was not accurate. There may be other fields of type measure like distances or weights.
The problem with durations that EFX-2 tries to solve is that unlike other measure type fields, durations have the unit embedded in the value. For example the value P1W means one week. Unlike durations for every other kind of measure like distances we keep two separate fields to store the measure: the standard field that holds the numeric value and an additional attribute field @unitCode tha...
Replies: 5 comments
Hi,
Could you please provide further details on the so called 'attribute'? Where was it to be found?
Thanks
All reactions
Hi,
the correct term is probably "Dynamic property".
You can find it in the Documentation (https://docs.ted.europa.eu/eforms/latest/fields/index.html#_dynamic_properties):
Image
And in the Fields.json (as i mentioned on BT-36-Lot):
ImageAll reactions
Hi,
I saw that EFX2 does not support this kind of rule and am looking for the answer to your question.
All reactions
Dear @JanEmde,
BT-36 is of type duration. SDK-2 changes the way we deal with durations which are in fact a specific type of measure. The problem in EFX-1 is that it would treat any measure field as duration. But that was not accurate. There may be other fields of type measure like distances or weights.
The problem with durations that EFX-2 tries to solve is that unlike other measure type fields, durations have the unit embedded in the value. For example the value P1W means one week. Unlike durations for every other kind of measure like distances we keep two separate fields to store the measure: the standard field that holds the numeric value and an additional attribute field @unitCode that holds the unit.
So, we had to separate duration type from measure type in SDK-2 to avoid this problem. As, SDK 1.15, is released during our transition to SDK-2 some of these changes could not be avoided and as a result you see this rule being removed from the field as we prepare the SDK metadata for SDK-2.
We are not discontinuing however dynamic rules, or numericRange rules. We just had to remove this rule from the particular field, because this particular field does not hold a numeric value but rather a string encoding an interval (duration) together with its unit.
I hope this helps,
Yannis