[
https://issues.apache.org/jira/browse/SLING-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17843164#comment-17843164
]
Karol Lewandowski edited comment on SLING-12302 at 5/3/24 10:26 AM:
--------------------------------------------------------------------
Hi, I have additional questions, if you don't mind. If there is a better
channel for this, please let me know.
1. I noticed that accessing nested configuration takes metadata from the parent
config resources.
Examples:
1. {{{}$\{caconfig['com.example.Config/nested']{}}}} - this will take default
values from {{com.example.Config}} annotation.
2. {{{}$\{caconfig['com.example.Config/nested/subnested']{}}}} - this will also
take default values from {{com.example.Config}} annotation.
This is the code responsible for this behavior:
[https://github.com/apache/sling-org-apache-sling-caconfig-impl/blob/master/src/main/java/org/apache/sling/caconfig/impl/ConfigurationBuilderImpl.java#L259-L269]
Correct me if I'm wrong, but I think that it is quite uncommon for nested
configuration resource properties to match the keys of parent properties.
There is a comment: "probably a configuration list - remove item name from
end", but it is unclear.
Why a nested configuration is considered a potential list and how is it related
to default values of the parent?
2. Is it expected that it is not possible to iterate nested configurations in
HTL?
I mean something like this:
- /conf/we-retail/sling:configs/us/en/sling:configs
-- com.example.Config
--- nestedList
---- item1
---- item2
---- item3
Annotations:
{code:java}
package com.example;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface Config {
NestedConfig[] nestedList();
}
{code}
{code:java}
package com.example;
public @interface NestedConfig {
String message();
}
{code}
Access in HTL:
{code:java}
<ul data-sly-list="$\{caconfig['com.example.Config/nestedList']}">
${item.message}
</ul>
{code}
Unfortunately, it doesn't work. The iteration is performed on the
{{com.example.Config/nestedList}} resource instead of items, which is an
iteration over its value map keys.
Is it expected? Is creating a Sling Model the only way to iterate over a nested
list?
Also, a general question: are there any general rules that shape the CA Config
support in HTL?
was (Author: karol.lewandowski):
Hi, I have additional questions, if you don't mind. If there is a better
channel for this, please let me know.
1. I noticed that accessing nested configuration takes metadata from the parent
config resources.
Examples:
1. {{{}$\{caconfig['com.example.Config/nested']{}}}} - this will take default
values from {{com.example.Config}} annotation.
2. {{{}$\{caconfig['com.example.Config/nested/subnested']{}}}} - this will also
take default values from {{com.example.Config}} annotation.
This is the code responsible for this behavior:
[https://github.com/apache/sling-org-apache-sling-caconfig-impl/blob/master/src/main/java/org/apache/sling/caconfig/impl/ConfigurationBuilderImpl.java#L259-L269]
Correct me if I'm wrong, but I think that it is quite uncommon for nested
configuration resource properties to match the keys of parent properties.
There is a comment: "probably a configuration list - remove item name from
end", but it is unclear.
Why a nested configuration is considered a potential list and how is it related
to default values of the parent?
2. Is it expected that it is not possible to iterate nested configurations in
HTL?
I mean something like this:
- /conf/we-retail/sling:configs/us/en/sling:configs
-- com.example.Config
--- nestedList
---- item1
---- item2
---- item3
Annotations:
{code:java}
package com.example;
import org.apache.sling.caconfig.annotation.Configuration;
@Configuration
public @interface Config {
NestedConfig[] nestedList();
}
{code}
{code:java}
package com.example;
public @interface NestedConfig {
String message();
}
{code}
Access in HTL:
{code:java}
<ul data-sly-list="$\{caconfig['com.example.Config/nestedList']}">
${item.message}
</ul>
{code}
Unfortunately, it doesn't work. The iteration is performed on the
{{com.example.Config/nestedList}} resource instead of items, which is an
iteration over its value map keys.
Is it expected? Is creating a Sling Model the only way to iterate over a nested
list?
> CA Config access syntax is inconsistent in HTL
> ----------------------------------------------
>
> Key: SLING-12302
> URL: https://issues.apache.org/jira/browse/SLING-12302
> Project: Sling
> Issue Type: Bug
> Reporter: Karol Lewandowski
> Assignee: Stefan Seifert
> Priority: Major
>
> I have a problem understanding how nested configs can be accessed in HTL or
> if there is a bug in the implementation.
> The
> [documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
> gives an example:
> {{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{}}}}
> However, it doesn't work when a configuration annotation class is defined.
> Steps to reproduce:
> 1. Create a config node:
> {{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
> xmlns:jcr="http://www.jcp.org/jcr/1.0"
> jcr:primaryType="sling:OsgiConfig"
> email="[email protected]"
> enabled="{Boolean}true"
> number="{Long}123">
> <nested
> jcr:primaryType="sling:OsgiConfig"
> greeting="hello"/>
> </jcr:root>
> {code}
> and reference it from some path.
> 2. Access in HTL without configuration annotation class:
> {code}
> Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
> Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
> Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
> Greeting (config path):
> ${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
> Greeting (property path):
> ${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
> This gives the output:
> {code}
> Email: [email protected]
> Number: 123
> Enabled: true
> Greeting (config path): hello
> Greeting (property path): hello {code}
> It works as expected.
> 3. Create annotation classes:
> {code:java}
> package com.mysite.core.config;
> import org.apache.sling.caconfig.annotation.Configuration;
> @Configuration
> public @interface TestConfig {
> String email();
> int number() default 5;
> boolean enabled();
> NestedConfig nested();
> }
> {code}
> and
> {code:java}
> package com.mysite.core.config;
> public @interface NestedConfig {
> String greeting();
> }
> {code}
> The previous HTL will print:
> {code}
> Email: [email protected]
> Number: 123
> Enabled: true
> Greeting (config path): hello
> Greeting (property path): {code}
> Accessing nested config value with property name path doesn't work. Is it
> expected?
> I'm working on support for CA Configs in AEM IDE, so I don't want to make it
> work in my AEM application but provide the correct syntax support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)