Escape special characters in subscription conditions?
Closed this issue · 8 comments
Description
Is it possible to escape special characters when writing a condition in a subscription?
Let's say we have users who want to write a condition where X == 'something/somethingElse' ?
Do we need to escape those characters within the JMESPath expression? What characters are allowed? The documentation needs to be updated with this information. Perhaps the front-end docs also?
Motivation
Users might want to match objects in the aggregation which contains special characters.
They need answers to:
- What characters are allowed to use in the JMESPath condition?
- Is it possible to escape special characters?
- If so, how to do it?
Exemplification
Benefits
More varied conditions can be written. Clear examples can help users get going faster.
Possible Drawbacks
None that I can think of.
I dont know exactly how special characters works here, but if they break something on the way a possibility is to url encode the string before sending it to back-end and url decode the string before using it. There should be test setup with subscriptions using such conditions.
An update: I've only tested that it is possible to use / in the JMESPath conditions but I can't really say for other special characters ...
Question: Regarding escaping the special characters, are you talking about the limitation of JEMSPath or limitation of code before calling to JMESPath...?
I think from a user perspective, the end result is the same. They need to know which (if any) special characters are not allowed to include in their subscription conditions. (If JMESPath expressions have these limitations or if i's somehtign extra we've added on top in Eiffel Intelligence (don't know why we would?) it doesn't really matter.
I think what I wanted when I wrote this issue was: if some characters are NOT allowed, i.e. because they will be url-encoded or parser etc, this needs to be documented properly. When I wrote the issue I was looking specifically for the / being allowed and had to test it to make sure it was possible to use. It could be that we do not have limitations, i.e. we allow any kind of String in the subcriptions condition, but then we need to clarify this in the documentation: what kind of syntax is expected.
And if some special characters are not allowed, is it possible to escape this in some JMESPath syntax or is it not possible to use them at all?
Well, to me it is like this. If it is JMESPath then we dont need to do anything as it is JMESPath. User know that he/she has to compose a JMESPath expression. What are the limitation/ syntax/ escape character, etc, are part of JMESPath is JMESPath. We cannot and shouldnt, even try to provide docs for anything about JMESPath, as it is illogical, unconventional as well as misleading for user. We can (and must) provide docs for our code. Our job is to provide users the limitations of our code.
I believe you mean this question to consider in this story:
Do our code require from user to escape some special characters...?
Well, to me it is like this. If it is JMESPath then we dont need to do anything as it is JMESPath. User know that he/she has to compose a JMESPath expression. What are the limitation/ syntax/ escape character, etc, are part of JMESPath is JMESPath. We cannot and shouldnt, even try to provide docs for anything about JMESPath, as it is illogical, unconventional as well as misleading for user. We can (and must) provide docs for our code. Our job is to provide users the limitations of our code.
I believe you mean this question to consider in this story:
Do our code require from user to escape some special characters...?
I see your point. I agree, if it's only limitations within JMESPath I believe it's enough to only reference their official documentation to refer our users there. (Currently such a link is missing (hard to find?) in the documentation)
Documentation merged.