为什么我们在CQ5中的单个组件有多个jsp？

Question

我是CQ5的新手。在学习它的概念时，我了解到CQ5使用Sling框架进行请求处理，并根据最佳匹配来解析脚本。我在CQ5中见过几个组件(大多数是页面组件或顶级组件)，它们在一个组件下有多个jsp (例如，页面组件有page.jsp，body.jsp，header.jsp类似的重定向组件有redirect.jsp，body.jsp，content.jsp)。所以我想问一下，在什么情况下，我们会有多个jsp，哪一个脚本会被sling解析来显示内容？

Answer 1

一个组件下有多个jsp的可能性与sling比CQ有更多的关系(尽管cq也在框架上提供了一些扩展)。在顶级组件(例如页面组件)中使用更多jsp的原因通常是为了捕获在较低级别的某个地方发生的include的情况(因此，包含文件的定义在那里，但实际的文件不在组件中)。

在我看来，在一个组件下拥有多个jsp有三个主要原因(不管是什么级别的)，所有这些原因都可以同时应用于同一个组件。

在更小(更易维护)的pieces

• Overriding rendering

• Using中拆分组件 sling

的强大功能

场景1:将组件拆分成更小(更易维护)的部分

正如标题所述，我们可以在一个组件中使用多个jsp来将该组件的呈现拆分成更易于维护和覆盖的单独部分，或者两者的组合。“两者”的情况是在基础页面组件中发生的事情。但请查看场景2以了解有关这方面的详细信息。

标准页面的呈现从具有模板的cq页面开始，该模板依次指定用于呈现的组件。所以跳过模板部分，直接转到实际的基础页面组件。在page.jsp中呈现页面开始部分。在中，通过包含"head.jsp“和"body.jsp”将其进一步分解。他们反过来又将其进一步拆分。这允许您重写子组件中页面组件的特定部分(请参阅场景2)。

场景2:重写呈现

假设您创建了自己的基本页面组件(common practise)，该组件继承自基础页面组件(通过sling:resourceSuperType属性)，并且您只对在主体中输出特定的html结构感兴趣。在本例中，您只需在“基页”组件中创建一个body.jsp文件。这实际上覆盖了body (在基础页面组件中)的呈现，但默认为其他所有内容(例如head、headlibs)，等等，取决于这些文件在父链中某处的可用性。在我们的例子中，它将默认在基础页面组件中指定的文件上。链将解析到您的基本组件，然后解析到基础页面组件(因为其中只有body.jsp，没有base.jsp)。在基础页面组件中，可以找到包含body.jsp (这将是在基础组件中定义的body.jsp )的page.jsp。

我们在这里所做的工作在所有层面上都有效。当继承其他组件而不是“页面”组件时，这个概念也会起作用。例如，我使用它覆盖了基础列表组件的呈现，其中我包含了一个jsp (sling.jsp)，而jsp(Jsp)反过来使用了一个带有特定选择器的sling include，然后使从该list组件继承的组件覆盖了sling include选择器。

场景3:使用吊索选择器的功能

由于sling具有“选择器”的概念，sling将沿着sling链向上移动，以找到正确的组件来呈现内容。Sling将始终使用最具体的选择器进行渲染。

例如，假设我创建了一个继承自基础title组件的title组件。假设我在title组件中有这样的结构。

title.jsp
h2.jsp
fancy.jsp

很明显，h2和for是title组件的实际选择器

将多个jsp与选择器组合在一起是一种常用的做法。它们用于以不同的方式显示基本上相同的组件。

您还可以将该h2.jsp放入页面组件中。如果你正确地设置链条，吊索就会找到它。

除了我在这里描述的，还有更多关于选择器的内容。但这只是问题的一部分。

Answer 2

通常，组件是由一个与请求匹配的脚本呈现的，我们称其为GET.jsp。

但是，在该脚本中，您只会发现其中包含对其他脚本调用，如body.jsp、header.jsp。这样做的目的是为了在/apps中覆盖另一个header.jsp (例如)，而不覆盖完整的GET.jsp脚本。