我是 CQ5 的新手。在学习它的概念时,我了解到 CQ5 使用 Sling 框架进行请求处理并根据最佳匹配解析脚本。我在 CQ5 中看到很少有组件(其中大多数是页面或顶级组件)在单个组件下有多个 jsp(例如页面组件有 page.jsp、body.jsp、header.jsp 类似的重定向组件有重定向.jsp、body.jsp、content.jsp)。所以我想问在什么场景下,我们会有多个jsp,哪个脚本会被sling解析来显示内容?
2 回答
一个组件下有多个 jsp 的可能性与 sling 的关系比与 CQ 的关系更大(尽管 cq 还提供了框架上的一些扩展)。在顶级组件(例如页面组件)中拥有更多 jsp 的原因通常是为了捕获在某个较低级别发生包含的情况(因此包含文件的定义在那里,但实际文件是组件中不存在)。
在我看来,在一个组件下拥有多个 jsp 有 3 个主要原因(无论是什么级别),所有这些原因都可以同时应用于同一个组件
- 将组件分解成更小(更易于维护)的部分
- 覆盖渲染
- 使用吊索选择器的力量
场景 1:将组件分解为更小(更易于维护)的部分
正如这里的标题所述,我们可以在一个组件中使用多个 jsp 来将该组件的呈现分成单独的部分,这些部分更易于维护和覆盖,或者两者兼而有之。“两者”情况是基础页面组件中发生的情况。但请查看场景 2 了解详情。
标准页面的渲染从具有模板的 cq 页面开始,该模板又指定用于渲染的组件。所以跳过模板部分,直接进入实际的基础页面组件。在 page.jsp 中呈现页面开始。通过包含“head.jsp”和“body.jsp”进一步分解它。他们反过来进一步分裂它。这允许您在子组件中覆盖页面组件的特定部分(参见场景 2)。
场景 2:覆盖渲染
假设您创建了自己的基础页面组件(常见做法),它继承自基础页面组件(通过 sling:resourceSuperType 属性),并且您只对在正文中吐出特定的 html 结构感兴趣。在这种情况下,您只需在该“基本页面”组件中创建一个 body.jsp 文件(仅此而已)。这实际上覆盖了正文(在基础页面组件中)的呈现,但默认为其他所有内容(例如 head、headlibs)等等,取决于父链中某处的这些文件的可用性。在我们的例子中,它将默认在基础页面组件中指定的文件上。该链将解析到您的基础组件,然后解析到基础页面组件(因为您那里只有 body.jsp 而没有 base.jsp)。在基础页面组件内部,页面。
我们在这里所做的工作适用于各个层面。当从“页面”组件之外的其他组件继承时,此概念也将起作用。例如,我用它来覆盖基础列表组件的渲染,其中我包含了一个 jsp (sling.jsp),它又使用带有特定选择器的 sling 包含,然后制作从该列表组件继承的组件和将吊索包含选择器覆盖为其他内容。
场景 3:使用吊索选择器的强大功能
由于 sling 有“选择器”的概念,所以 sling 会沿着 sling 链向上找到正确的组件来渲染内容。Sling 将始终使用最具体的选择器进行渲染。
例如,假设我创建了一个继承自基础标题组件的标题组件。假设我在标题组件中有这个结构。
title.jsp
h2.jsp
fancy.jsp
很明显 h2 和 fancy 是 title 组件的实际选择器
将多个 jsp 与选择器结合使用是一种常用的做法。这些用于以不同的方式显示基本相同的组件。
您还可以将该 h2.jsp 放在您的页面组件中。如果您正确设置链条,吊索会找到它。
选择器比我在这里描述的要多。但这只是问题的一部分。
通常,一个组件由一个匹配请求的脚本呈现,我们称之为GET.jsp
。
但是,在该脚本中,您只会发现对其他脚本的包含调用,例如 body.jsp、header.jsp。这样做是为了在/apps
不覆盖完整的 GET.jsp 脚本的情况下覆盖另一个 header.jsp(例如 )。