Simplify same-page conditionals: Remove `existingValue`. [#3005884]

While digging around the same-page conditional code I came to wonder what was the meaning of the (undocumented) existingValue argument for the JS-comparison handlers.

It seems they are needed for rule groups that span multiple form pages. Example:

page1 (1 component): one
page2 (2 components): two, one & two (depending on both one and two).

With the current code on page2 the full conditional group is put into the settings. Because the form element for one is not present on page2 its value is passed in the settings and then passed to the comparson callback as existingValue.

I think this could be simplified easily by evaluating the comparison callbacks for components from earlier pages on the server side. This would remove a pitfall from implementing new comparison operators and conditional types.

Comment	File	Size	Author
#2	3005884-conditionals-remove-existingValue-2.patch	12.98 KB	torotil

Comments

Comment #1

11 October 2018 at 09:07

torotil created an issue. See original summary.

Comment #2

torotil commented 15 October 2018 at 10:12

Status:

Active

» Needs review

Status	File	Size
new	3005884-conditionals-remove-existingValue-2.patch	12.98 KB

Here is a simple implementation of this idea. These are the changes made:

Factor out the server-side comparison evaluation into WebformConditionals::executeComparison().
Introduce a new source_type for JS evaluation that simply provides the evaluated value.
If a component from a previous page is rendered for a component rule in webform_conditional_prepare_javascript() render a “result” rule instead.
Change the existing comparisons to just ignore the now unused existingValue argument. Comparison operators are guaranteed to only be invoked on the same page as their element.

In an ideal world we could even make further calculations on the server-side to eliminate the already evaluated rules (and possibly some others as well).