[
https://issues.apache.org/jira/browse/NIFI-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15127456#comment-15127456
]
Andy LoPresto commented on NIFI-1121:
-------------------------------------
Is this something that could be implemented using {{onPropertyModified}}? It
would know the property that changed and could evaluate any "children" of that
property and mark their "visibility" as a boolean depending on a custom
interpreter that is provided at {{processor.init()}}? Is {{onPropertyModified}}
UI only or is that triggered via the API as well?
> Allow components' properties to depend on one another
> -----------------------------------------------------
>
> Key: NIFI-1121
> URL: https://issues.apache.org/jira/browse/NIFI-1121
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Mark Payne
>
> Concept: A Processor developer (or Controller Service or Reporting Task
> developer) should be able to indicate when building a PropertyDescriptor that
> the property is "dependent on" another Property. If Property A depends on
> Property B, then the following should happen:
> Property A should not be shown in the Configure dialog unless a value is
> selected for Property B. Additionally, if Property A is dependent on
> particular values of Property B, then Property A should be shown only if
> Property B is set to one of those values.
> For example, in Compress Content, the "Compression Level" property should be
> dependent on the "Mode" property being set to "Compress." This means that if
> the "Mode" property is set to Decompress, then the UI would not show the
> Compression Level property. This will be far less confusing for users, as it
> will allow the UI to hide properties that irrelevant based on the
> configuration.
> Additionally, if Property A depends on Property B and Property A is required,
> then a valid value must be set for Property A ONLY if Property B is set to a
> value that Property A depends on. I.e., in the example above, the Compression
> Level property can be required, but if the Mode is not set to Compress, then
> it doesn't matter if the Compression Level property is set to a valid value -
> the Processor will still be valid, because Compression Level is not a
> relevant property in this case.
> This provides developers to provide validation much more easily, as many
> times the developer currently must implement the customValidate method to
> ensure that if Property A is set that Property B must also be set. In this
> case, it is taken care of by the framework simply by adding a dependency.
> From an API perspective, it would manifest itself as having a new "dependsOn"
> method added to the PropertyDescriptor.Builder class:
> {code}
> /**
> * Indicates that this Property is relevant if and only if the parent property
> has some (any) value set.
> **/
> Builder dependsOn(PropertyDescriptor parent);
> {code}
> {code}
> /**
> * Indicates that this Property is relevant if and only if the parent
> property is set to one of the values included in the 'relevantValues'
> Collection.
> **/
> Builder dependsOn(PropertyDescriptor parent, Collection<AllowableValue>
> relevantValues);
> {code}
> In providing this capability, we will not only be able to hide properties
> that are not valid based on the Processor's other configuration but will also
> make the notion of "Strategy Properties" far more powerful/easy to use. This
> is because we can now have a Property such as "My Capability Strategy" and
> then have properties that are shown for each of the allowed strategies.
> For example, in MergeContent, the Header, Footer, Demarcator could become
> dependent on the "Bin-Packing Algorithm" Merge Strategy. These properties can
> then be thought of logically as properties of that strategy itself.
> This will require a few different parts of the application to be updated:
> * nifi-api - must be updated to support the new methods.
> * nifi-framework-core - must be updated to handle new validation logic for
> components
> * nifi-web - must be updated to show/hide properties based on other
> properties' values
> * nifi-mock - needs to handle the validation logic and ensure that developers
> are using the API properly, throwing AssertionErrors if not
> * nifi-docs - need to update the Developer Guide to explain how this works
> * processors - many processors can be updated to take advantage of this new
> capability
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
