[ https://issues.apache.org/jira/browse/NIFI-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Payne resolved NIFI-1121. ------------------------------ Resolution: Fixed > 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 > Affects Versions: 1.11.4 > Reporter: Mark Payne > Assignee: M Tien > Priority: Major > Fix For: 1.13.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > 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 (v8.3.4#803005)