Qute user tags - use defaulted keys if appropriate #22003
Conversation
|
@FroMage This is the initial attempt to solve #21861. It should solve the problem with |
|
OK thanks. This is missing docs though. And I really think tags should be isolated by default, as every programming language function. Naturally, for tags that accept a body, the body should be resolved in the context of the parent, and not the tag. But again, exactly the same scoping rules as Java and most modern programming languages. |
Yes, it's not documented because I'm still not convinced of the param name... Maybe something like
Well, I'll be repeating myself but tags are IMO not functions but more like a specialized include directives. I get your point but I'm hesitating to change the default behavior and introduce another breaking change. Moreover, we would have to follow the same rules for |
|
I don't know what external scope is visible from includes, that's not obvious from https://quarkus.io/guides/qute-reference#include_helper In general, I really think we should stick to programming language semantics, especially Java, because that's what make the most sense for Quarkus devs. |
It's simply the parent scope. The docs mention "The included template can reference data from the current context.".
+1 but it's a pity we did not catch this a few dozen versions back :-( |
- i.e. for params that define no key and contain only single part - also use Mapper instead of Map for the data passed to a template - Mapper value resolver has priority 15, i.e. is called before a generated value resolver - resolves quarkusio#21855 - related to quarkusio#21861
|
I've updated the docs. Let's merge this now and we can decide to change the default behavior later... @FroMage WDYT? |
|
Well, now you've pretty much set it in stone in the docs that the current behaviour is dynamic scoping, so people may start using it. If you agree that this is the direction we should go do, we should make the change now that people are most likely not relying on dynamic scoping for user tags, and perhaps include a configuration setting to enable the old behaviour in case people depend on it? |
The current behaviour is "dynamic scoping" and it was like that since the beginning.
This PR merely clarifies the current behavior and I am still not sure which direction to go. But I agree that we should decide in the scope of 2.7. I can create a new discussion topic and we can create a follow-up PR if we decide to do a breaking change. |
|
I've created #22285 |
|
I'm going to merge this one, let's continue the discussion in #22285. |
generated value resolver