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

Extend documentation of custom filters #744

Merged
merged 3 commits into from
Nov 16, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 36 additions & 2 deletions book/src/filters.md
Original file line number Diff line number Diff line change
Expand Up @@ -408,18 +408,25 @@ This will output formatted YAML for any value that implements the required
## Custom Filters
[#custom-filters]: #custom-filters

To define your own filters, simply have a module named filters in scope of the context deriving a `Template` impl.
To define your own filters, simply have a module named `filters` in scope of the context deriving a `Template` impl and defines the filters as functions within this module. The functions must have a first argument `&str`, but otherwise can have other inputs. The output must be `::askama::Result<String>`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are actually no restrictions on the arguments, and while the return type must be an ::askama::Result<T>, T can be of any type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!
I was checking it again and wanted to say that "the first argument to the filter is a reference to the expression it is applied to", but it is not totally true and found some unexpected (for me) behaviour:

Consider the templates

{{ 2|my_filter }}

and

{{ (1 + 1)|my_filter }}

I would expect both to work the same, but they do not: the first case is 2 is given directly to my filter, while in the second case &(1 + 1) is given as reference.

The problem arises for the signature of the filter: should it take a reference or not?

fn my_filter(n: usize) -> ::askama::Result<String>

works for the first case and

fn my_filter(n: &usize) -> ::askama::Result<String>

works for the second.

Question.
Is this expected for you, or should 2 be past a reference &2?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is expected, although I agree that it is quite subtle -- would be great to document it! I think the recommended way to abstract over the difference would be to use a trait. For example, std::fmt::Display has a blanket implementation for &T where T: std::fmt::Display, so you could take an impl std::fmt::Display and receive either a &T or a T. In other cases, you might be able to define your own trait in a similar way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay!
To document what values are given as references and which are not, where can I look?
I would assume that everything that needs evaluation, is the result of a filter, or is a field is passed by reference. But literal values are passed without reference. Where should I look for these "literal values"?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should not document the exact rules, since they might change across otherwise semver-compatible releases. See Expr::is_copyable() for the heuristics we're using. That method is actually slightly misnamed -- naming it the other way around might make more sense (something like needs_borrow()).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect! I changed the wording, I hope it is clear enough without too much detail.


Note that in case of name collision, the built in filters take precedence.
Note that built-in filters have preference over custom filters, so, in case of name collision, the built-in filter is applied.

### Examples

Implementing a filter that replaces all instances of `"oo"` for `"aa"`.
```rust
use askama::Template;

#[derive(Template)]
#[template(source = "{{ s|myfilter }}", ext = "txt")]
struct MyFilterTemplate<'a> {
s: &'a str,
}

// Any filter defined in the module `filters` is accessible in your template.
mod filters {
// This filter does not have extra arguments
pub fn myfilter(s: &str) -> ::askama::Result<String> {
Ok(s.replace("oo", "aa"))
}
Expand All @@ -430,3 +437,30 @@ fn main() {
assert_eq!(t.render().unwrap(), "faa");
}
```

Implementing a filter that replaces all instances of `"oo"` for `n` times `"a"`.
```rust
use askama::Template;

#[derive(Template)]
#[template(source = "{{ s|myfilter(4) }}", ext = "txt")]
struct MyFilterTemplate<'a> {
s: &'a str,
}

// Any filter defined in the module `filters` is accessible in your template.
mod filters {
// This filter requires a `usize` input when called in templates
pub fn myfilter(s: &str, n: usize) -> ::askama::Result<String> {
let mut replace = String::with_capacity(n);
replace.extend((0..n).map(|_| "a"));
Ok(s.replace("oo", &replace))
}
}

fn main() {
let t = MyFilterTemplate { s: "foo" };
assert_eq!(t.render().unwrap(), "faaaa");
}
```