Find a way to avoid too much nesting when using Qute

[ia3andy]

Description

Interested in this extension, please +1 via the emoji/reaction feature of GitHub (top right).

{#include main.html}
{#title}My Notes{/title}
<p>Hello</p>
{/include}

could be replaced by:

include: main.html
title: My Notes
---
<p>Hello</p>

Repository name

quarkus-qute-frontmatter

Short description

Allow to use frontmatter alongside Qute to make layout a bit simpler

Repository Homepage URL

https://quarkiverse.github.io/quarkiverse-docs/quarkus-qute-frontmatter/dev/

Repository Topics

• quarkus-extension
• qute
• template
• frontmatter
• layout

Team Members

• @ia3andy
• @mkouba

Additional context

Zulip discussion: https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/Frontmatter.20extension.20for.20Qute

[quarkus-bot]

You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip

This message is automatically generated by a bot.

[quarkus-bot]

/cc @mkouba (qute)

[maxandersen]

Why is frontmatter something to tie into qute?
isn't it something relevant to apply to all kinds of content ? HTML, markdown, liquid, handlebar etc.?

[ia3andy]

Why is frontmatter something to tie into qute? isn't it something relevant to apply to all kinds of content ? HTML, markdown, liquid, handlebar etc.?

Those would be different extensions as to be able to do this you have to tie it to the underlying template engine AFAIK

[maxandersen]

Those would be different extensions as to be able to do this you have to tie it to the underlying template engine AFAIK

yes - hence its not really a qute thing; but a "blog-generator" thing.

Like, what is the usecase for the notion of frontmatters only on qute templates? and would it fit into quarkus typesafe templates etc?

[ia3andy]

Those would be different extensions as to be able to do this you have to tie it to the underlying template engine AFAIK

yes - hence its not really a qute thing; but a "blog-generator" thing.

Like, what is the usecase for the notion of frontmatters only on qute templates? and would it fit into quarkus typesafe templates etc?

for the first question I think other frontmatter extension could also make sense, but Qute is the one I use with Quarkus.

For the secodn question about type safety, @mkouba might know more

[mkouba]

and would it fit into quarkus typesafe templates etc?

For the secodn question about type safety, @mkouba might know more

As I explained in the zulip discussion - I think that the best way to implement this would be to add a custom content filter that would modify the template before it's parsed. Basically, replace the frontmatter with qute tags. This should not affect type-safe templates. However, keep in mind that similar solutions can be brittle...

[FroMage]

I already proposed a shorter syntax in #8750 a long time ago, and lost that battle:

{#set title}My Title{/} 
{#extend base/}
<div>
  My body.
</div>

That looks more Qute-spirited and shorter than frontmatter ;)

[maxandersen]

@FroMage +1 - expanding/simplifying the syntax of Qute's ability to composite templates makes more sense to me than adding a "flat" frontmatter.

[mkouba]

I already proposed a shorter syntax in #8750 a long time ago, and lost that battle:

{#set title}My Title{/} 
{#extend base/}
<div>
  My body.
</div>

That looks more Qute-spirited and shorter than frontmatter ;)

Well, I don't find this proposal more readable or even Qute-spirited and it definitely does not follow the current syntax rules.

And BTW this particular example could be simplified like:

{#include base title='My Title'}
<div>...  // this would be used for {#insert}
{/}

and then in the base <title>{title ?: 'Default title'}</title> .

[ia3andy]

This is joining something I am not a fan of, everything has to be nested in Qute, even when declaring variables with let (https://quarkus.io/guides/qute-reference#let_section). TBH the first time I used let I was really disturbed by the syntax.

Maybe we should have a syntax to change the current context?

This way we could set an include and it's params without nesting?

[mkouba]

everything has to be nested in Qute, even when declaring variables with let

Yes, the idea is that the tag defines the scope of the variable. For include , however, the end tag defines where the included section ends. Because you can do things like:

{#include foo}
 ...
{/include}

And now for something completely different. // -> not part of the included template at all

We could relax this requirement and make the end tag optional for some sections. We already do that for the nested blocks in the {#include} section where the end tag is automatically added before the start of the next block or the end of the include section.

So that if you use {#let foo=true} without the end tag in your template then {/let} would be "automatically added" at the end of the template. It should work but we need to be careful...

[ia3andy]

Ah that could be a solution indeed (for both problems), I would auto-add the end tag at the end of the current section though (not the end of the template)

[ia3andy]

Then we could just do:

{#include base title='My Title'}
<p>blahblah</p>
{#for item in items} 
		{#let foo = item.price}
       <li>{item.name} {#if item.active}{foo}{/if}</li>           
{/for}    

[ia3andy]

I would be happy with such a happy ending :)

[mkouba]

I would auto-add the end tag at the end of the current section though (not the end of the template)

👍

[mkouba]

FYI I've created #33293

[mkouba]

Closing this issue as #33296 was merged. Feel free to reopen if necessary.