Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.11.4
-
None
Description
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:
/** * Indicates that this Property is relevant if and only if the parent property has some (any) value set. **/ Builder dependsOn(PropertyDescriptor parent);
/** * 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);
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
Attachments
Issue Links
- relates to
-
-
- Open
-
- links to
