我是 CQ5 的新手。在学习它的概念时，我了解到 CQ5 使用 Sling 框架进行请求处理并根据最佳匹配解析脚本。我在 CQ5 中看到很少有组件（其中大多数是页面或顶级组件）在单个组件下有多个 jsp（例如页面组件有 page.jsp、body.jsp、header.jsp 类似的重定向组件有重定向.jsp、body.jsp、content.jsp）。所以我想问一下，在什么场景下，我们会有多个jsp，哪个脚本会被sling解析来显示内容？
【问题讨论】：
在一个组件下有多个 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）。在基础页面组件中，找到 page.jsp，其中包含 body.jsp（将是在基础组件中定义的 body.jsp）。
我们在这里所做的工作适用于所有级别。当从“页面”组件之外的其他组件继承时，此概念也将起作用。例如，我用它来覆盖基础列表组件的渲染，其中我包含了一个 jsp (sling.jsp)，它又使用带有特定选择器的 sling 包含，然后制作从该列表组件继承的组件和将 sling 包含选择器覆盖为其他内容。
场景 3：使用吊索选择器的强大功能
由于 sling 有“选择器”的概念，sling 会沿着 sling 链向上找到正确的组件来渲染内容。 Sling 将始终使用最具体的选择器进行渲染。
例如，假设我创建了一个继承自基础标题组件的标题组件。假设我在标题组件中有这个结构。
title.jsp
h2.jsp
fancy.jsp
很明显 h2 和 fancy 是标题组件的实际选择器
将多个 jsp 与选择器结合使用是一种常用的做法。这些用于以不同的方式显示基本相同的组件。
您也可以将 h2.jsp 放在您的页面组件中。如果您正确设置链条，吊索会找到它。
选择器比我在这里描述的要多。但这只是问题的一部分。
【讨论】：
通常一个组件由一个匹配请求的脚本呈现，我们称之为GET.jsp。
但是，在该脚本中，您只能找到对其他脚本的 include 调用，例如 body.jsp、header.jsp。这样做是为了您可以在 /apps 中覆盖另一个 header.jsp（例如 ），而不会覆盖完整的 GET.jsp 脚本。
【讨论】：