Mark Payne created NIFI-1121:
--------------------------------
Summary: 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)
