Improve the field value parsing for choice widgets to handle null values
#12247
Conversation
…d unit test This commit follows the same pattern as another unit test in this file and both reduces existing and future code duplication (since the next commit will extend this test with an additional input).
…alues The specification states that the field value is `null` if no item is selected and we didn't handle this case properly. Even though this did not break the rendering because we always convert the value to an array and the `includes` check in the display layer would simply not match, the field value would be `[null]` which is not expected and strange from an API perspective. This commit fixes that by ensuring that we return an empty array in case the field value is `null`. The API therefore still always gives an array for the field value, but now the code is more specific so that the value is either an empty array or an array of strings.
timvandermeij
force-pushed
the
acroform-choice-null
branch
from
e5f030f to
12c2077
Compare
|
/botio unittest |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @timvandermeij received. Current queue size: 0 Live output at: http://54.215.176.217:8877/72c8e4379ffae4d/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/a15b5a9c41b13b5/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/a15b5a9c41b13b5/output.txt Total script time: 3.76 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/72c8e4379ffae4d/output.txt Total script time: 4.95 mins
|
|
/botio test |
From: Bot.io (Windows)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 0 Live output at: http://54.215.176.217:8877/f4a3bf234132852/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/e8507c5b248510f/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/e8507c5b248510f/output.txt Total script time: 26.99 mins
Image differences available at: http://54.67.70.0:8877/e8507c5b248510f/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/f4a3bf234132852/output.txt Total script time: 29.22 mins
Image differences available at: http://54.215.176.217:8877/f4a3bf234132852/reftest-analyzer.html#web=eq.log |
The specification states that the field value is
nullif no item is selected and we didn't handle this case properly. Even though this did not break the rendering because we always convert the value to an array and theincludescheck in the display layer would simply not match, the field value would be[null]which is not expected and strange from an API perspective.This commit fixes that by ensuring that we return an empty array in case the field value is
null. The API therefore still always gives an array for the field value, but now the code is more specific so that the value is either an empty array or an array of strings.Fixes something I noticed while debugging #12233 (see https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf#page=454&zoom=auto,-215,765 for the specification).
Slightly easier review with the
?w=1parameter.