[
https://issues.apache.org/jira/browse/NIFI-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093442#comment-16093442
]
Pierre Villard commented on NIFI-4149:
--------------------------------------
The only problematic situation I can think of is when a property is expecting a
regular expression. IIRC we have properties accepting both but it could require
specific handling if we are using the combination of regex and EL. To be
confirmed.
I guess we could deprecate the {{evaluateAttributeExpressions()}} and directly
make the call in {{getValue()}} (and similar methods). For the UX, I'd say that
we could deprecate {{supportsExpressionLanguage()}} in the builders and add a
method like you suggest: {{supportsFlowFileExpressions()}}. I agree that the
tooltip should also be updated to reflect the change.
Also agree regarding lifecycle.
> Indicate if EL is evaluated against FFs or not
> ----------------------------------------------
>
> Key: NIFI-4149
> URL: https://issues.apache.org/jira/browse/NIFI-4149
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Pierre Villard
>
> With the addition of EL in a lot of places to improve SDLC and workflow
> staging, it becomes important to indicate to users if the expression language
> enabled on a property will be evaluated against the attributes of incoming
> flow files or if it will only be evaluated against various variable stores
> (env variables, variable registry, etc).
> Actually, the expression language (without evaluation against flow files)
> could be allowed on any property by default, and evaluation against flow
> files would be what is actually indicated in the UI as we are doing today.
> Adopting this approach could solve a lot of JIRA/PRs we are seeing to add EL
> on some specific properties (without evaluation against FFs).
> Having expression language to access external values could make sense on any
> property for any user. However evaluating the expression language against FFs
> is clearly a more complex challenge when it comes to session management and
> such.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)