核心组件遵循与基础组件截然不同的现代实现模式。
本页介绍这些模式,以及何时使用这些模式构建您自己的可创作组件。 第一部分一般组件模式适用于任何类型的组件,而第二部分可重用组件模式适用于计划跨站点或项目重用的组件,例如核心组件。
本节中的准则建议用于任何类型的组件,无论该组件是否特定于单个项目,或该组件是否打算跨站点或项目广泛重复使用。
组件可以具有包含各种选项的对话框。 应利用此功能,使组件变得灵活、可配置,并避免实施多个组件,这些组件大多是彼此不同的组件。
通常,如果线框或设计包含相似元素的变体,则这些变体不应作为不同的元件实现,而应作为具有在这些变体之间进行选择的一个元件。
要更进一步,如果组件在站点或项目之间重复使用,请参阅预配置功能部分。
将组件的逻辑(或模型)与标记模板(或视图)分开通常是一种好做法。 实现此目的有多种方法,但建议使用Sling Models作为逻辑,使用HTML模板语言(HTL)作为标记,如核心组件也这样做。
Sling Models是一组Java注释,用于从POJO轻松访问所需的变量,因此,它优惠一种简单、强大而高效的方法来为组件实施Java逻辑。
HTL设计为一种安全、简单的模板语言,专为AEM量度身定制。 它可以调用多种形式的逻辑,使其非常灵活。
本节中的准则也可用于任何类型的组件,但对于希望跨站点或项目重复使用的组件(例如核心组件),它们最有意义。 因此,对于仅用于单个站点或项目的组件,可以忽略这些准则。
除了页面作者使用的编辑对话框外,组件还可以具有模板作者的设计对话框,供模板作者预配置。 模板编辑器允许设置所有这些预配置,这些预配置称为“策略”。
为使组件尽可能地可重用,应为它们提供有意义的预配置选项。 这将允许或禁用组件功能以匹配不同站点的特定需求。
由于每个内容资源都有一个sling:resourceType
属性,它引用组件来呈现它,因此通常最好将这些属性指向特定于站点的组件,而不是指向由多个站点共享的组件。 如果一个站点需要组件的不同行为,这将优惠更多的灵活性并避免内容重构,因为随后可以在特定于站点的组件上实现此自定义,而不会影响其他站点。
但是,对于不重复任何代码的项目特定组件,它们应分别引用具有sling:resourceSuperType
属性的共享父组件。 这些主要只引用父组件的项目特定组件称为“代理组件”。 如果代理组件完全继承该功能,则它们可以是完全空的,也可以重新定义组件的某些方面。
随着时间的推移,组件应保持完全兼容,但有时,无法保持兼容的更改是必要的。 解决这些对立需求的一个解决方案是通过在其资源类型路径和实现的完全限定的Java类名称中添加数字来引入组件版本控制。 此版本号表示由语义版本准则定义的主要版本,该版本仅对不向后兼容的更改递增。
对组件的以下方面进行不兼容的更改将生成新版本:
有关详细信息,请参阅GitHub中的版本控制策略文档。
组件版本控制创建了一种合同形式,该形式对升级很重要,因为它澄清了何时可能需要对某些内容进行重构。 另请参阅自定义的升级兼容性一节,其中解释了不同形式的自定义升级需要哪些注意事项。
为避免痛苦的内容迁移,切勿直接指向内容资源中的版本化组件。 根据经验,sling:resourceType
的内容永远不得包含版本号,或者升级组件也需要重新构造内容。 避免这种情况的最佳方法是遵循上述代理组件模式。
此模式与HTL的data-sly-use
指令相关,指向Java接口,而Sling Model实现也将自身注册到组件的资源类型。
如果与上述代理组件模式结合使用,则这种多次绑定优惠形式会遵循良好的扩展点:
以下是整个资源类型绑定结构的概述,以标题核心组件为例。 它说明了站点特定的代理组件如何能够解析组件版本控制,以避免内容资源包含任何版本号。 然后,它显示组件的title.html
HTL文件如何用于模型接口,而实现通过Sling Model注释绑定到组件的特定版本。
下面是另一个概述,它不显示实施POJO的详细信息,但显示关联的模板和策略如何被引用。
cq:allowedTemplates
属性告诉哪些模板可用于站点,cq:template
则告诉每个页面关联的模板是什么。 每个模板由以下三部分组成:
AEM Project Archety 将最小的Adobe Experience Manager项目视为您自己项目的起点,包括一个使用SlingModels的自定义HTL组件的示例,用于逻辑和使用推荐的代理模式正确实施核心组件。
阅读下一篇文章: