Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow escaping keys in templates #149

Closed
LucasPickering opened this issue Apr 9, 2024 · 0 comments · Fixed by #271
Closed

Allow escaping keys in templates #149

LucasPickering opened this issue Apr 9, 2024 · 0 comments · Fixed by #271
Labels
feature New behavior to enable things that were previously not possible help wanted Extra attention is needed

Comments

@LucasPickering
Copy link
Owner

Right now templates don't allow expressing all strings. For example, there's no way to write a template that's just the raw string {{user_id}}. If you write {{user_id}}, it parses as a key and will try to render the field user_id.

A couple ideas:

  • Precede key with backslash: \{{user_id}}
    • This should be fairly simple to implement in the parser. I gave it a good effort but couldn't figure it out in nom. Also tried chumsky but got bored. Maybe just needs another crack
    • We would also need to make backslashes escapable, so you can precede a template key with a literal backslash (e.g. so you can render \\{{user_id}} to \\abc123, if user_id = abc123
  • Inner quotes in template, e.g. {{'{{user_id}}'}} renders as {{user_id}}
    • This is what jinja does, apparently
    • Now we need to make single quotes inside the nested quotes escapable

Definitely leaning toward the first option. However it's done, Template::dangerous should be replaced with Template::escaped, which generates a template of the raw string. Additionally, we need to update the template serialization to escape parsed content. For example, if we have a parsed template that's just the raw string {{user_id}}, then it should serialize as \{{user_id}} (or however we decide to do escaping).

@LucasPickering LucasPickering added the feature New behavior to enable things that were previously not possible label Apr 9, 2024
@LucasPickering LucasPickering modified the milestone: 1.0 Apr 9, 2024
@LucasPickering LucasPickering added the help wanted Extra attention is needed label Apr 18, 2024
@LucasPickering LucasPickering added this to the 1.5.0 milestone Jun 9, 2024
@LucasPickering LucasPickering removed this from the 1.5.0 milestone Jun 18, 2024
LucasPickering added a commit that referenced this issue Jun 23, 2024
This is a major change to parsing, including replacing nom with winnow. While this is technically a breaking change because it changes the behavior of existing templates, in practice the number of templates that will be affected is likely zero. The escape sequences were very unlikely to be used previously.

Closes #149
LucasPickering added a commit that referenced this issue Jun 23, 2024
This is a major change to parsing, including replacing nom with winnow. While this is technically a breaking change because it changes the behavior of existing templates, in practice the number of templates that will be affected is likely zero. The escape sequences were very unlikely to be used previously.

This has some potential performance issues, because it involves cloning raw sections of text unnecessarily. This may lead to a lot of wasted work. There's room for optimizing the common path where no escape sequences are used. That will come in another PR though.

Closes #149
LucasPickering added a commit that referenced this issue Jun 23, 2024
This is a major change to parsing, including replacing nom with winnow. While this is technically a breaking change because it changes the behavior of existing templates, in practice the number of templates that will be affected is likely zero. The escape sequences were very unlikely to be used previously.

This has some potential performance issues, because it involves cloning raw sections of text unnecessarily. This may lead to a lot of wasted work. There's room for optimizing the common path where no escape sequences are used. That will come in another PR though.

Closes #149
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New behavior to enable things that were previously not possible help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant