[
https://issues.apache.org/jira/browse/NIFI-4149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409875#comment-16409875
]
ASF GitHub Bot commented on NIFI-4149:
--------------------------------------
Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/2205
Hey @pvillard31 I definitely where this is going. I agree that another
PR/JIRA can be issued for the more elaborate indication of processor-specific
variables in the EL. The only issue that I have with this as-is, is that if we
have processor that still indicates `.expressionLanguageSupported(true)`, in
the UI all that it says is "Expression Language Scope: NONE" and that believes
me to believe that Expression Language is not supported. I think if the
processor still indicates `true` instead of the Scope, that we still show in
the UI: "Expression Language Supported: true" or whatever it is that we show
currently.
The only other note, which is very minor, is that in the UI I would avoid
showing the Scope as NONE, VARIABLE_REGISTRY, FLOWFILE_ATTRIBUTES and instead
use human-friendly syntax: "Not Supported", "Variable Registry Only" and
"Variable Registry and FlowFile Attributes" - perhaps just update
ExpressionLanguageScope enum to contain a "description" or something and then
populate the DTO with that? Thoughts on that?
> 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
> Assignee: Pierre Villard
> Priority: Major
>
> 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
(v7.6.3#76005)
