我不熟悉蓝图,但据我了解,这只是生成 CQ 项目结构的一种方式,因此我认为它对您管理配置参数的方式没有任何实际影响。
CQ5 基于Apache Sling,它使用 OSGi ConfigAdmin 服务来配置参数,并提供一些工具来简化此操作。
您可以在PathBasedDecorator Sling 组件中看到一个示例,该组件使用 @Component 注释将自己声明为 OSGi 组件:
@Component(metatype=true, ...)
之后使用@Property 注解声明一个多值可配置参数,具有默认值:
@Property(value={"/content:2", "/sling-test-pbrt:2"}, unbounded=PropertyUnbounded.ARRAY)
private static final String PROP_PATH_MAPPING = "path.mapping";
然后在组件的 activate() 方法中读取该值:
final Dictionary<?, ?> properties = componentContext.getProperties();
final String[] mappingList = (String[]) properties.get(PROP_PATH_MAPPING);
并且包含该组件的 OSGi 包提供了一个metatype.properties文件来定义可配置参数的名称和标签。
就是这样——有了这个,Sling 和 OSGi 框架为组件生成了一个基本的配置 UI,您可以从 /system/console/config 访问它,并在配置参数更改时自动管理组件的激活和重新激活。
这些配置也可以来自 JCR 存储库,这要感谢 Sling 安装程序在那里拾取它们,您可以在 CQ5 存储库的 /libs 和 /apps 下名为“config”的文件夹中找到许多配置。
另一种选择是直接使用 JCR 内容,具体取决于您的可配置参数的使用方式。您可以告诉您的组件其配置位于存储库中的 /apps/foo/myparameters 下(并仅使该值可配置),并根据需要在该节点下添加 JCR 属性和子节点,以便您的组件可以读取。缺点是当参数改变时你的@Component 不会自动重启,就像直接使用 OSGi 配置时一样。
冗长的解释......希望这会有所帮助;-)