Qute: tag parameters from outer space

[FroMage]

Describe the bug

This one is funky:

test.html:

Class: {class}<br/>
Size: {size}

Usage: {#test class="myclass"/}

Result:

Class: class io.quarkus.qute.Mapper$1
Size: 3

So… I can't use the class parameter name, I need to use klass in order to be able to pass my values. And for some reason, if I don't specify a size parameter on the call site, the tag still has a value for it, so it can't test whether it was passed or not with size?? and it appears pretty random from the PoV of the user.

I know @mkouba told me there's a place where this size comes from, and there might be other reserved parameter names that are tricky like this, but we should probably remove them because they can really clash with what the user is doing. Unless there's a good reason for them existing?

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @mkouba

[mkouba]

Class: class io.quarkus.qute.Mapper$1

This should not happen unless a value resolver is generated for the io.quarkus.qute.Mapper class. And it does not happen if I do:

Engine engine = Engine.builder()
                .addDefaults()
                .addSectionHelper(new UserTagSectionHelper.Factory("myTag", "my-tag-id"))
                .strictRendering(false)
                .build();

        Template tag = engine.parse("Class: {class}");
        engine.putTemplate("my-tag-id", tag);
        assertEquals("Class: myclass", engine.parse("{#myTag class=\"myclass\"/}").render());

So we'll need more context here to reproduce the problem. Anyway, it should be easy to fix - set the priority used for the default Mapper value resolver to a value greater than ValueResolverGenerator.DEFAULT_PRIORITY.

Size: {size}

Yes, this one comes from the parent context, namely the from the data map passed to the template. Again, should be easy to fix the default behavior - wrap the map with a Mapper instance. Of course, this would not help if a user sets a custom map as a template data. But that's not very common.

...but we should probably remove them because they can really clash with what the user is doing. Unless there's a good reason for them existing?

I'm not sure TBH. The current behavior is that you can access the data from the parent/outer context because we thought that it might be useful. We could implement a breaking change and disable the access by default but then we should probably make it configurable, i.e. some special attribute {#test class="myclass" _parent=true /}.

[FroMage]

So we'll need more context here to reproduce the problem

How can I find which resolver prints this, then?

should be easy to fix the default behavior - wrap the map with a Mapper instance

I assume this is done by Qute itself, right?

The current behavior is that you can access the data from the parent/outer context because we thought that it might be useful

Wait, parent context of what? The tag? So you can access data from outside the tag itself? Not just its parameters?