Added the dbg and format filters #517
Conversation
| @@ -145,6 +145,12 @@ pub fn as_str(value: &Value, _: &HashMap<String, Value>) -> Result<Value> { | |||
| to_value(&value.render()).map_err(Error::json) | |||
| } | |||
|
|
|||
| /// Prints the passed value to stdout before returning it | |||
| pub fn dbg(value: &Value, _: &HashMap<String, Value>) -> Result<Value> { | |||
There was a problem hiding this comment.
I don't think this should be a default filter, people might want to log instead etc
There was a problem hiding this comment.
I don't think it's a bad thing as if someone wants log they can just make one. This is mainly (as with the dbg!() macro) for debugging. I've found that in nearly every project I've done with Tera I end up recreating this, and it's simple enough to add
There was a problem hiding this comment.
It's easy to add as you say so I would keep it out of the builtins one.
There was a problem hiding this comment.
Is this function even related to formatting? Should it be a separate PR?
| }; | ||
|
|
||
| Ok(Value::String(value)) | ||
| } |
There was a problem hiding this comment.
Is that exactly what Jinja2 is doing?
Can we add a link to the implementation?
There was a problem hiding this comment.
That wasn't based on Jinja, it was just based on Rust, I have no knowledge of what Jinja does
There was a problem hiding this comment.
Tera is trying to roughly match what Jinja is doing. The format filter of Jinja is essentially printf (https://jinja.palletsprojects.com/en/2.11.x/templates/#format) so it would need match functionality if it has the same name. We could rename it to avoid confusion
There was a problem hiding this comment.
Implementing printf(https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting) is quite involved. I wonder how much of would actually get used and if a Rust programmer would know what to do with it. I can see the point of staying close to Jinja2, but matching printf is more like staying close to Python.
There was a problem hiding this comment.
Yep that's fine, just need to rename it so people using both are not confused by having the same name but different functionalities.
| @@ -145,6 +145,12 @@ pub fn as_str(value: &Value, _: &HashMap<String, Value>) -> Result<Value> { | |||
| to_value(&value.render()).map_err(Error::json) | |||
| } | |||
|
|
|||
| /// Prints the passed value to stdout before returning it | |||
| pub fn dbg(value: &Value, _: &HashMap<String, Value>) -> Result<Value> { | |||
There was a problem hiding this comment.
Is this function even related to formatting? Should it be a separate PR?
| }; | ||
| let mut chars = fmt.chars(); | ||
|
|
||
| if !matches!(chars.next(), Some(':')) { |
There was a problem hiding this comment.
I don't see matches! macro being used anywhere else in this project. Should it be an IF or MATCH ?
There was a problem hiding this comment.
matches!() is in the stdlib.
| }; | ||
|
|
||
| Ok(Value::String(value)) | ||
| } |
There was a problem hiding this comment.
Implementing printf(https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting) is quite involved. I wonder how much of would actually get used and if a Rust programmer would know what to do with it. I can see the point of staying close to Jinja2, but matching printf is more like staying close to Python.
|
If you can split dbg from format yes |
|
What is your opinion on including the formatting as a parameter to the |
dbgfilter which prints the passed value to stdout (similar to thedbg!()macro)formatfilter, which offers various integer formatting routines such as:xand:XCloses #474