diggernet commented on PR #13:
URL: https://github.com/apache/velocity-tools/pull/13#issuecomment-1320649785
While I totally agree with you in general about libraries ignoring RFC, I'm
not sure I understand your frustration with regards to this change. This has
nothing to do with any RFC.
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636051#comment-17636051
]
Christopher Schultz commented on VELTOOLS-184:
--
I stand corrected.
> EscapeTool: add a
ChristopherSchultz commented on PR #13:
URL: https://github.com/apache/velocity-tools/pull/13#issuecomment-1320571869
Because that would require more code.
IMO less code is always better if you can get away with it. This is adding
code just for the sake of adding code.
I'm not
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636048#comment-17636048
]
Maurice Perry edited comment on VELTOOLS-184 at 11/18/22 9:56 PM:
--
You
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636048#comment-17636048
]
Maurice Perry commented on VELTOOLS-184:
You misread the RFC: any character can be escaped
arkanovicz commented on PR #13:
URL: https://github.com/apache/velocity-tools/pull/13#issuecomment-1320455340
The current state of the patch is to propose `$esc.json()` (which didn't
exist) as an alias for `$esc.java()`. I'm reluctant to escape things that don't
have to be, not in regard
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17636011#comment-17636011
]
Claude Brisson commented on VELTOOLS-184:
-
There may be broken Json parsers in the wild, but
ChristopherSchultz commented on PR #13:
URL: https://github.com/apache/velocity-tools/pull/13#issuecomment-1320432439
I think buggy libraries which ignore `RFC-MUST` should be fixed or made to
die. There is no reason this patch should be necessary.
--
This is an automated message from
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635999#comment-17635999
]
Christopher Schultz edited comment on VELTOOLS-184 at 11/18/22 7:12 PM:
[
https://issues.apache.org/jira/browse/VELTOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17635999#comment-17635999
]
Christopher Schultz commented on VELTOOLS-184:
--
I'm sorry, but whatever JSON parser you
diggernet commented on PR #13:
URL: https://github.com/apache/velocity-tools/pull/13#issuecomment-1320348077
I'm fine with a synonym too, unless some future issue is raised for
compatibility. The main point is to have $esc.json() present, since the most
obvious alternative of
arkanovicz commented on PR #13:
URL: https://github.com/apache/velocity-tools/pull/13#issuecomment-1320314516
Well, EcmaScript is not Json. I don't know of any valid reason to escape <'>
and in Json, so I don't mind having an `esc.json()` method, but it should
just ba a synonym of
diggernet commented on PR #13:
URL: https://github.com/apache/velocity-tools/pull/13#issuecomment-1320290688
That's a fair question. I suppose the lazy answer is "because escapeJson()
exists". :)
Comparing escapeJava() and escapeJson() shows they differ on two characters:
/ and
arkanovicz commented on PR #13:
URL: https://github.com/apache/velocity-tools/pull/13#issuecomment-1319738744
I see in StringEscapeUtils the following comment for `escapeEcmaScript()`:
> The only difference between Java strings and EcmaScript strings
> is that in EcmaScript, a
14 matches
Mail list logo
