Open PanoramicPanda opened 5 years ago
I'm leaning toward the concept of a "validation reliant on" property on elements. Takes an element and will only run the validation step of the current element if the one it relies on is active.
Extend ElementGroup
to have a method to apply this to all elements in a group, and now you can create as many table rows as you want, but it will only care to validate a row if the element it relies on is active.
This would still validate that Row 3's elements in the above example would be deactivated, but it wouldn't care about a Row 4, 5, 6, etc.
Oz is primarily based on creating all of your elements up front. Say you have the following row of a table:
If we want to fill this out or validate it in anyway, we just define each of the 4 fields. No problem
However, we fill the first row and now it looks like this:
If you use any sort of loop or enumerator to create elements for each and every possible field, you could wind up with hundreds of extra fields that you don't need to be validating every time. It's usually enough to validate that the next row isn't active/present.
Making it based on the keys within
INPUT_DATA
feels like it goes against some of Oz's patterns - namely the ability to land on a page with one data target (thus hittingcreate_elements
) but then filling the page with a different one.I feel like the approach should be a
TableElement
of sorts, but again, struggling to think of how to stick to Oz's patterns of creating all the elements of the page, but yet only validating the rows we care about.