gpt4 book ai didi

aem - 根据 Sling 选择器在 Sightly 中显示不同的标记

转载 作者:行者123 更新时间:2023-12-02 20:48:59 25 4
gpt4 key购买 nike

上下文

我正在开发一个使用 Sightly 作为模板语言的 AEM 6 项目。我面临一个用例,其中我想根据 Sling 选择器的存在来显示或隐藏标记的某些部分。

例如,对 /content/my-project/my-page.html 的请求应产生基本页面 View ,并且当向 /content/my-project 发出请求时/my-page.ubermode.html,Sling 应该返回由略有不同的 HTML 文档表示的相同内容。

根据the Sling Cheat Sheet ,应该可以使用不同的脚本。

我设法通过放置两个 Sightly 脚本 mycomponent.htmlubermode.html(以选择器命名)在组件中实现此目的

/apps/(...)/mycomponent
|- .content.xml
|- _cq_editConfig.xml
|- dialog.xml
|- mycomponent.html
|- ubermode.html

当涉及到 HTML 结构时,这确实需要一些代码重复,但效果很好。

但是,在这种特殊情况下,我需要在渲染器级别进行同样的思考(我们称之为 myapp/core/renderers/fancyPageRenderer)。更重要的是,渲染器有一个不同的渲染器作为其 sling:resourceSuperType(让我们称之为父渲染器 myapp/core/renderers/genericPageRenderer),并依赖于一系列中等复杂的包含(data-sly-include)。

fancyPageRenderer 中,我覆盖了 genericPageRenderer 中最初定义并包含的脚本之一。这是我希望在使用 ubermode 选择器时有所不同的部分。我们将此脚本称为 mainColumn.html

我尝试了不同的命名约定来匹配选择器,但没有一个以令人满意的方式工作。

这是最初的结构

/apps/(...)/renderers/fancyPageRenderer
|- .content.xml
|- mainColumn.html //this overrides a script included by a parent renderer

这是我尝试过的:

/apps/(...)/renderers/fancyPageRenderer
|- .content.xml
|- mainColumn.uber.html
|- mainColumn.html

这根本不起作用,每次都会包含mainColumn.html

<小时/>
/apps/(...)/renderers/fancyPageRenderer
|- .content.xml
|- uber.html
|- mainColumn.html

这导致使用 uber.html 脚本,但生成的页面不包含 genericPageRenderer 中包含的其他脚本中定义的任何标记

<小时/>

我想我可以将所有相关脚本复制到 fancyPageRenderer 中,但这会导致大量且完全 Not Acceptable 代码重复。

我也知道可以手动add, remove or replace selectors using data-sly-resource或者只使用原始选择器,但就我而言,广泛使用的是 data-sly-include 而不是 data-sly-resource

有没有一种优雅的方法来解决这个问题?

最佳答案

最终,我放弃了使用脚本命名约定来解决这个问题,并在渲染器的 Sightly 脚本中公开了一个非常简单的 Sling 模型。

这是 fancyPageRenderer 的当前结构(与原始结构相比没有改变):

/apps/(...)/renderers/fancyPageRenderer
|- .content.xml
|- mainColumn.html //this overrides a script included by the parent renderer

这是我在 mainColumn.html Sightly 脚本中使用的内容:

 <div class="fancy main-column" data-sly-use.uberMode="com.foo.bar.myapp.fancy.UberMode">
<div data-sly-test="uberMode.enabled" >Uber-mode-only-content</div>
<!-- Lots of markup here -->
<div data-sly-test="!uberMode.enabled" >Explicitly non-uber-mode content</div>
<div>Common content (but some uber-mode-dependend, nested divs as well, rendered the same way as above)</div>
</div>

以及底层的 Sling 模型,UberMode

@Model(adaptables = SlingHttpServletRequest.class)
public class UberMode {

@Inject
SlingHttpServletRequest request;

private boolean enabled = false;

@PostConstruct
public void postConstruct() {
if (request != null) {
List<String> selectors = Arrays.asList(request.getRequestPathInfo().getSelectors());
enabled = selectors.contains("ubermode");
}
}

public boolean isEnabled() {
return enabled;
}
}

这使我能够避免 Sightly 中的代码重复,并使基于选择器的逻辑可进行单元测试。另外,当我需要多个选择器来决定渲染什么时,依赖命名约定会变得非常棘手。相比之下,向此类添加对另一个相关选择器的支持将非常简单。

它也给我留下了很多重构选项。我可以从使用选择器切换到使用查询参数或 header ,并且只编写几行代码,甚至无需接触 Sigthly 脚本,该脚本实际上是我的类的客户端代码。

关于aem - 根据 Sling 选择器在 Sightly 中显示不同的标记,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28571842/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com