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

Reimplement {% filter %} block #73

Merged
merged 4 commits into from
Jul 13, 2024

Conversation

Kijewski
Copy link
Collaborator

This PR reimplements the code generation for {% filter %} blocks, so that the data is written directly into its destination writer, without using a buffer. This way it behaves like a specialized {{ expr|filter1|filter2 }} would, if the expr was a Template that contained the body of the filter block.

@Kijewski Kijewski force-pushed the pr-reimpl-filter-block branch 2 times, most recently from ea6b71a to 064ce2e Compare July 13, 2024 06:38
@Kijewski
Copy link
Collaborator Author

Kijewski commented Jul 13, 2024

I did not understand the code of {% filter %} blocks at all, so I took a stab at re-implementing them, I hope that's okay! I wouldn't have been able to review the other PR.

My implementation seems to be sane, but your tests, @GuillaumeGomez, expect different whitespaces than my code emits. To me it looks like my implementation works correctly. Could you please have a look if the tests or the implementation is wrong?

@Kijewski Kijewski force-pushed the pr-reimpl-filter-block branch 2 times, most recently from ad2cb30 to 451e75c Compare July 13, 2024 07:17
@GuillaumeGomez
Copy link
Contributor

The output seems correct indeed. The code looks code as well. Very good idea to use a closure! Some tests of mine are missing.

If you don't mind, I'll merge #71, like that you will have tests already and will just need to update them.

@Kijewski
Copy link
Collaborator Author

If you don't mind, I'll merge #71, like that you will have tests already and will just need to update them.

Sure, that's the simplest solution!

@GuillaumeGomez
Copy link
Contributor

Perfect thanks! Just waiting for your review before merging it then. ;)

@GuillaumeGomez
Copy link
Contributor

Ok, a rebase and fixed tests and then please ping me for review. :)

In my opinion it's much easier to read than `&mut (impl …)`. Also, it
might come in handy to have access to the type in the generator.
The case can occur in filter blocks. In a normal filter expression, we
don't emit the auto escaper code for `|safe` or `|escape`.
This PR reimplements the code generation for `{% filter %}` blocks, so
that the data is written directly into its destination writer, without
using a buffer. This way it behaves like a specialized
`{{ expr|filter1|filter2 }}` would, if the `expr` was a `Template` that
contained the body of the filter block.
@GuillaumeGomez GuillaumeGomez changed the title Reimplement {% filter %} block Reimplement {% filter %} block and make paragraphbreaks safe by default Jul 13, 2024
@GuillaumeGomez
Copy link
Contributor

This is so much better, thanks a lot! I also updated the title of the PR about the paragraphbreaks filter.

@GuillaumeGomez GuillaumeGomez merged commit 24c91e1 into rinja-rs:master Jul 13, 2024
17 checks passed
@Kijewski
Copy link
Collaborator Author

This is so much better, thanks a lot!

Thank you! Yeah, I assumed that this feature could be implemented with a closure and after a while of testing it actually worked! :)

I also updated the title of the PR about the paragraphbreaks filter.

Oops, I didn't do that in this PR. :/ I only changed |e and |safe.

@Kijewski Kijewski deleted the pr-reimpl-filter-block branch July 13, 2024 09:27
@GuillaumeGomez
Copy link
Contributor

Woups. Being woken up too early by the cat is bad for my brain haha. Please fix my fix of the title. ^^'

@Kijewski Kijewski changed the title Reimplement {% filter %} block and make paragraphbreaks safe by default Reimplement {% filter %} block Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants