[
https://issues.apache.org/jira/browse/NIFI-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Moran updated NIFI-2069:
----------------------------
Attachment: interpret-escape-sequences_nifi-2...@2x.png
See the attached *interpret-escape-sequences_nifi-2...@2x.png* for a sample of
how this could be implemented into the new design.
* Group the 'interpret' on/off control with the textarea as it directly affects
what is entered
* Visually separate the empty string checkbox as it will override/ignore any
value that was previously entered
* Use more descriptive language with all controls to better explain what each
will do
As the new design evolves we should look for opportunities to use
context-sensitive help that can provide users even more clarity as the interact
with the UI.
> Add option to UI to enter interpreted vs literal text
> ------------------------------------------------------
>
> Key: NIFI-2069
> URL: https://issues.apache.org/jira/browse/NIFI-2069
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Joseph Percivall
> Attachments: interpret-escape-sequences_nifi-2...@2x.png, mock-up.png
>
>
> In adding the PutTCP processor there has been some debate over accepting "\n"
> as the literal characters "\" and "n" vs the character for a new line.
> Currently the UI will pass the literal values and it's on the processor to
> decide what to do with them. Leading to multiple processors to interpret
> "\n", "\t" or "\r" entered in the UI as a new line, tab and carriage return
> respectively.
> It is reasonable for a user to want enter "\n" as a new line but it is also
> not correct to be inconsistent in how the user enters values throughout the
> UI. When entering a string in the UI there should be a second checkbox (next
> to "Empty") for "Interpreted" (name subject to change). This would allow
> users to select whether the values the enter are interpreted ("\n" -> new
> line character) vs literals ("\n" -> "\" and "\n"). Also this should allow
> for the support for entering unicode characters.
> In order to keep backwards compatibility the default would be not interpreted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
