nifi-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Payne (JIRA)" <>
Subject [jira] [Created] (NIFI-1121) Allow components' properties to depend on one another
Date Fri, 06 Nov 2015 22:55:10 GMT
Mark Payne created NIFI-1121:

             Summary: Allow components' properties to depend on one another
                 Key: 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:

* 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

This message was sent by Atlassian JIRA

View raw message