I’ve created a pull request that hides the ‘+’ UI element as necessary.
https://github.com/apache/nifi/pull/969
I’ll open a second Jira ticket to start the discussion around adding an
additional tag to add user-supplied tags to flow files.
- Kirk Tarou
On 8/22/16, 6:06 PM, "Tarou, Kirk"
I created ticket a Jira ticket to remove the + icon:
https://issues.apache.org/jira/browse/NIFI-2629
The existence of a “DynamicProperty” annotation could be used to determine
whether to show the icon.
I’m making an initial attempt to add a ‘hasDynamicProperty’ field to the
processor API
For #1, totally agree that if a processor doesn't support dynamic properties
then the UI element could be hidden or disabled.
For #2, I like the additional tab idea, it basically enables a decorator
pattern on the processor to add attributes without any onus on any part of the
flow to use
Kirk,
As Matt points out dynamic properties of processors have meaning
specific to those processors. So, we need to be careful to avoid
complicating that.
You raise two other points there though that I'd like to further discuss:
1) Processors that don't really support dynamic properties should
I think it would be beneficial to add dynamic properties to any processor
for use further down the flow, not in the processor where the properties
are added.
For example, I may have a lot of ŒListSFTP¹ processors that feed into a
single FetchSFTP, then a single PutFile. It would be nice to be
Kirk,
The processors have to explicitly know about dynamic properties (and
their intent) in order to use them appropriately. For a processor like
ListSFTP, it could be beneficial to have custom attributes (as
parameters to the SFTP session perhaps?) but the domain knowledge on
how they'd be used
Is there some reason why Processors, like ListSFTP, don’t allow custom
attributes to be added? Relatedly, why do these processors allow users to add
custom attributes & values in the UI even though it always throws the error:
‘[attribute]’ validated against ‘[value]’ is invalid because
