AP-22850: Improve Row Filter node description wrt. output domain info…

…rmation

AP-22850 (Row Filter node description incorrectly describes domain behavior)

org.knime.base.tests/files/test_snapshots/org.knime.base.node.preproc.filter.row3.RowFilterNodeSettingsSnapshotTest.snap

@@ -22,7 +22,7 @@
               "title" : "Compute"
             } ],
             "title" : "Column domains",
-            "description" : "Specify whether to take input column domains as output domains or compute them on output columns.\nDepending on the use case, one or the other setting may be preferable:\n\n<ul>\n    <li><em>Retaining</em> input columns can be useful, if the axis limits of a view should be derived from\n    domain bounds, and that bounds should stay stable even when the displayed data is filtered.\n    </li>\n    <li><em>Computing</em> domains can be useful when a selection widget consumes the output and should only\n    display actually present options to users.</li>\n</ul>\n\nIf column domains are irrelevant for a particular use case, the &quot;Retain&quot; option should be used\nsince it does not incur computation costs.\n\nFor more control over column domains, you can use the <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.dialog2.DomainNodeFactory        \"><em>Domain Calculator</em></a>, <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.editnumeric.EditNumericDomainNodeFactory        \"><em>Edit Numeric Domain</em></a>, or <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.editnominal.EditNominalDomainNodeFactory        \"><em>Edit Nominal Domain</em></a> nodes.\n\n<ul>\n<li><b>Retain</b>: Retain input domains on output columns</li>\n<li><b>Compute</b>: Compute column domains on output columns</li>\n</ul>",
+            "description" : "<p>Specify whether to take domains of all input columns as output domains as-is or compute them on the output\nrows.</p>\n\n<p>\nDepending on the use case, one or the other setting may be preferable:\n<ul>\n    <li><em>Retaining</em> input columns can be useful, if the axis limits of a view should be derived from\n    domain bounds, and that bounds should stay stable even when the displayed data is filtered.\n    </li>\n    <li><em>Computing</em> domains can be useful when a selection widget consumes the output and should only\n    display actually present options to users.</li>\n</ul>\n</p>\n\n<p>\nIf column domains are irrelevant for a particular use case, the &quot;Retain&quot; option should be used\nsince it does not incur computation costs.\n</p>\n\n<p>\nFor more control over individual column domains, you can use the <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.dialog2.DomainNodeFactory        \"><em>Domain Calculator</em></a>, <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.editnumeric.EditNumericDomainNodeFactory        \"><em>Edit Numeric Domain</em></a>, or <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.editnominal.EditNominalDomainNodeFactory        \"><em>Edit Nominal Domain</em></a> nodes.</p>\n\n<ul>\n<li><b>Retain</b>: Retain input domains on output columns, i.e. the upper and lower bounds or possible values in the table spec\nare not changed, even if one of the bounds or one value is fully filtered out from the output table.\nIf the input does not contain domain information, so will the output.\n</li>\n<li><b>Compute</b>: Compute column domains on output columns, i.e. upper and lower bounds and possible values are computed only\non the rows output by the node.\n</li>\n</ul>",
             "default" : "RETAIN"
           },
           "matchCriteria" : {

org.knime.base.tests/files/test_snapshots/org.knime.base.node.preproc.filter.row3.RowSplitterNodeSettingsSnapshotTest.snap

@@ -22,7 +22,7 @@
               "title" : "Compute"
             } ],
             "title" : "Column domains",
-            "description" : "Specify whether to take input column domains as output domains or compute them on output columns.\nDepending on the use case, one or the other setting may be preferable:\n\n<ul>\n    <li><em>Retaining</em> input columns can be useful, if the axis limits of a view should be derived from\n    domain bounds, and that bounds should stay stable even when the displayed data is filtered.\n    </li>\n    <li><em>Computing</em> domains can be useful when a selection widget consumes the output and should only\n    display actually present options to users.</li>\n</ul>\n\nIf column domains are irrelevant for a particular use case, the &quot;Retain&quot; option should be used\nsince it does not incur computation costs.\n\nFor more control over column domains, you can use the <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.dialog2.DomainNodeFactory        \"><em>Domain Calculator</em></a>, <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.editnumeric.EditNumericDomainNodeFactory        \"><em>Edit Numeric Domain</em></a>, or <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.editnominal.EditNominalDomainNodeFactory        \"><em>Edit Nominal Domain</em></a> nodes.\n\n<ul>\n<li><b>Retain</b>: Retain input domains on output columns</li>\n<li><b>Compute</b>: Compute column domains on output columns</li>\n</ul>",
+            "description" : "<p>Specify whether to take domains of all input columns as output domains as-is or compute them on the output\nrows.</p>\n\n<p>\nDepending on the use case, one or the other setting may be preferable:\n<ul>\n    <li><em>Retaining</em> input columns can be useful, if the axis limits of a view should be derived from\n    domain bounds, and that bounds should stay stable even when the displayed data is filtered.\n    </li>\n    <li><em>Computing</em> domains can be useful when a selection widget consumes the output and should only\n    display actually present options to users.</li>\n</ul>\n</p>\n\n<p>\nIf column domains are irrelevant for a particular use case, the &quot;Retain&quot; option should be used\nsince it does not incur computation costs.\n</p>\n\n<p>\nFor more control over individual column domains, you can use the <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.dialog2.DomainNodeFactory        \"><em>Domain Calculator</em></a>, <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.editnumeric.EditNumericDomainNodeFactory        \"><em>Edit Numeric Domain</em></a>, or <a href=\"\nhttps://hub.knime.com/knime/extensions/org.knime.features.base/latest/org.knime.base.node.preproc.domain.editnominal.EditNominalDomainNodeFactory        \"><em>Edit Nominal Domain</em></a> nodes.</p>\n\n<ul>\n<li><b>Retain</b>: Retain input domains on output columns, i.e. the upper and lower bounds or possible values in the table spec\nare not changed, even if one of the bounds or one value is fully filtered out from the output table.\nIf the input does not contain domain information, so will the output.\n</li>\n<li><b>Compute</b>: Compute column domains on output columns, i.e. upper and lower bounds and possible values are computed only\non the rows output by the node.\n</li>\n</ul>",
             "default" : "RETAIN"
           },
           "matchCriteria" : {

org.knime.base/src/org/knime/base/node/preproc/filter/row3/AbstractRowFilterNodeSettings.java

@@ -342,36 +342,49 @@ private DynamicValuesInput keepCurrentValueIfPossible(final DynamicValuesInput n
     FilterCriterion[] m_predicates;
 
     @Widget(title = "Column domains", description = """
-            Specify whether to take input column domains as output domains or compute them on output columns.
-            Depending on the use case, one or the other setting may be preferable:
+            <p>Specify whether to take domains of all input columns as output domains as-is or compute them on the output
+            rows.</p>
 
+            <p>
+            Depending on the use case, one or the other setting may be preferable:
             <ul>
                 <li><em>Retaining</em> input columns can be useful, if the axis limits of a view should be derived from
                 domain bounds, and that bounds should stay stable even when the displayed data is filtered.
                 </li>
                 <li><em>Computing</em> domains can be useful when a selection widget consumes the output and should only
                 display actually present options to users.</li>
             </ul>
+            </p>
 
+            <p>
             If column domains are irrelevant for a particular use case, the &quot;Retain&quot; option should be used
             since it does not incur computation costs.
+            </p>
 
-            For more control over column domains, you can use the <a href="
+            <p>
+            For more control over individual column domains, you can use the <a href="
             """ + ExternalLinks.HUB_DOMAIN_CALCULATOR + """
                     "><em>Domain Calculator</em></a>, <a href="
             """ + ExternalLinks.HUB_EDIT_NUMERIC_DOMAIN + """
                     "><em>Edit Numeric Domain</em></a>, or <a href="
             """ + ExternalLinks.HUB_EDIT_NOMINAL_DOMAIN + """
-                    "><em>Edit Nominal Domain</em></a> nodes.
+                    "><em>Edit Nominal Domain</em></a> nodes.</p>
             """)
     @ValueSwitchWidget()
     @Layout(DialogSections.Output.class)
     ColumnDomains m_domains = ColumnDomains.RETAIN;
 
     enum ColumnDomains {
-        @Label(value = "Retain", description = "Retain input domains on output columns")
+        @Label(value = "Retain", description = """
+            Retain input domains on output columns, i.e. the upper and lower bounds or possible values in the table spec
+            are not changed, even if one of the bounds or one value is fully filtered out from the output table.
+            If the input does not contain domain information, so will the output.
+                """)
         RETAIN,
-        @Label(value = "Compute", description = "Compute column domains on output columns")
+        @Label(value = "Compute", description = """
+            Compute column domains on output columns, i.e. upper and lower bounds and possible values are computed only
+            on the rows output by the node.
+                """)
         COMPUTE;
     }
 

org.knime.base/src/org/knime/base/node/preproc/filter/row3/RowFilterNodeFactory.java

@@ -69,11 +69,6 @@ public final class RowFilterNodeFactory extends WebUINodeFactory<RowFilterNodeMo
                 Each criterion can target the row number, RowID, or cell value of a row.
                 Multiple criteria can be combined (similar to boolean logic via <tt>AND</tt> and <tt>OR</tt>)
                 to specify the overall filter criterion applied to each row.
-
-                <i>Note:</i> The domain of the input table is passed through as-is,
-                i. e. the upper and lower bounds or the possible values in the table spec are not changed,
-                even if one of the bounds or one value is fully filtered out from the output table. If the input
-                does not contain domain information, so will the output.
                 """) //
         .modelSettingsClass(RowFilterNodeSettings.class) //
         .addInputTable(RowSplitterNodeFactory.INPUT, RowSplitterNodeFactory.INPUT_DESCRIPTION) //