-
-
Notifications
You must be signed in to change notification settings - Fork 215
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
Tracking issue for unsupported Jinja features #427
Comments
I unpinned both of these issues again. In my opinion, matching Jinja feature-for-feature is a non-goal. I'd prefer to build something smaller and only add features if there are requests for features with a clear use case: making something much easier to express than it would otherwise be, in a way that can't be done without adding a feature to the core parser/codegen. Additionally, I value that the transformation from template to Rust code is easy to understand. While Python actually has an |
I pinned both, as then it would be quicker to find them for me. Finding the filters issue, requires browsing through the issues. Overall I agree with the sentiment. I've removed keyword arguments from the issue. However, I do see an exception with With that said, I'm not saying all tests necessarily have to be implemented, as e.g. Personally, I do have uses for Ultimately you decide. I feel it would be easier if you edited the issue, and just removed the ones you don't want. Then I know which I should and shouldn't spent time implementing. 😅 |
My issue with pinning these is that it could convey a signal to others browsing the issues that matching Jinja feature for feature is a goal, which I'd prefer to discourage. I'm fine with having line statements, |
Ah. From a perspective that someone might only read the title, then yeah, that's understandable. Alright, I'll look into implementing these when I have time. |
Hey there. Thanks for you work! Are there any plans on implementing this?
|
Not that I'm aware of. I'd be happy to guide you if you want to take a stab at it, though. Right now I don't remember much context about how macros work, but I think macro definitions are stored in the |
This is a tracking issue of an excerpt of unsupported Jinja features, as specified in Jinja's Template Designer Documentation.
The goal is not to list all unsupported features, but mainly focus on features that are useful or otherwise fit in Askama.
Missing filters are not included, as these are already tracked in issue #18.
The included features, are those that seem feasible to implement in Rust.
loop.cycle("odd", "even")
(Implement {{loop.cycle(…)}} similar to Jinja #517){% if loop.index0 % 2 == 0 %}odd{% else %}even{% endif %}
loop.cycle("foo", "bar", "baz", "qux")
, which would make it less trivial to express with{% if %}
loop.length
,loop.revindex
,loop.revindex0
len()
fromExactSizeIterator
, that way they are guaranteed to be exactExactSizeIterator
is only required, ifloop.length
, etc is usedloop.previtem
,loop.nextitem
Clone
loop.previtem
as undefined on the first iteration, so either it could becomeOption<T>
orT
if it implicitlyunwrap()
edloop.changed
, "True if previously called with a different value (or not called at all)."{% if loop.changed(entry.category) %}
{% for user in users if not user.hidden %}
( Implement for-else #518)if
infor
could simplify template codefilter()
on the iterator{% for ... %}{% else %}{% endfor %}
( Implement for-else #518)else
infor
would simplify handling for loops with no iterations{% if foo is defined %}
is_some()
check, along with anunwrap()
, i.e.if let Some
foo is defined
is checked in the generator, and checks if thefoo
field exists in the template struct.some
test instead, i.e.{% if foo is some %}
would then translate intoif let Some(foo) = &foo
foo.bar is some
might be more convoluted, as it would need to translate intoif let Some(bar) = &foo.bar
, while any subsequent use offoo.bar
would need to be additionally translated tobar
even
,odd
,divisibleby
starting_with
,ending_with
,containing
containing
is implemented, then it might make sense to include Jinja'sin
operator as a better shorthand{% macro input(name, value="", type="text", size=20) %}
{% call ... %}{% endcall %}
andcaller()
and inside macros{% filter upper %}This text becomes uppercase{% endfilter %}
{% set foo %}Capture the contents of a block{% endset %}
~
), e.g.{{ "foo " ~ 2 }}
, which would translate toformat!("{}{}", "foo ", 2)
{{ self::foo("bar " ~ 2) }}
, which otherwise wouldn't be feasible to do, this case might come up, if someone has aurl_for
function, with a path created dynamically from fieldsThe text was updated successfully, but these errors were encountered: