[Qute] Allow nested content for user defined tags

[jlannoy]

Hello.
Here is a first PR for a quick modification in Qute.

It will allow nested content in user defined tags. For a simple example, if I defined tags\my-tag.html as this :

<div class="{class}">
    {nested}
</div>

I can then call it this way :

{#my-tag class='large div'}
    <b>Hello !</b>
{\}

nested being a special key as it already is.

[jlannoy]

Can someone explain me or correct the PR to have a better (reactive) way than using a StringBuilder to manage the MultiNode results to inject into the nested var ?

[gsmet]

Just a note that this will need to be squashed before merging.

@mkouba could you have a look at that one?

[mkouba]

@jlannoy Could you pls describe your use case a little bit more? At least the expected output of your snippet would be helpful. I'm not sure I'm following...

[jlannoy]

The expected output is :

<div class="large div">
    <b>Hello !</b>
</div>

It's like the different section tags you can define in the include Qute directive. But oriented for custom tags development, so that you can have tag attributes and tag content. Like any HTML tag. It's a feature you can find in templating systems that offer kind of custom tags, like RockerBody in Rocker, <#nested /> in Freemarker... It seems a legit way to write more complex custom tags. Without this you have to write something like this, in my example :

{#my-tag class='large div' content='<b>Hello</b>' /}

Some other libraries don't allow it, like Velocity (velocimacros doesn't have this feature). I think you can achieve the same (when having a complex content) by using the set directive ; so you can decide to not support it.

[mkouba]

Now I finally undestand! ;-) I think it's a nice feature. The only thing I'm not quite sure about is the name of the key. content, body or nested-content could be a better choice? Let me check the modifications.

[jlannoy]

For the name of the key, I used nested in reference to Freemarker. In your proposals, nested-content is the more accurate and less risky I think, to avoid collision with other user defined variables.

[mkouba]

@jlannoy I think that the current version is OK. Would you care to review my changes?

[jlannoy]

Ok for me. Thank your for your help with the CompletionStage concept :)

[gastaldi]

That looks cool!

Guillaume's comments should be addressed now.