单页应用程序(SPA)可以为网站用户优惠引人入胜的体验。 开发人员希望能够使用SPA框架构建站点,而作者希望无缝编辑AEM中的内容,以便使用此类框架构建站点。
本文介绍了在让前端开发者开发SPA for AEM时应考虑的重要问题,并概述了AEM的体系结构以及部署SPA on AEM的方法。
在AEM上开发单页应用程序时,假定前端开发人员在创建SPA时遵循标准最佳做法。 如果您作为前端开发者,遵循这些一般的最佳实践以及AEM特定的一些原则,SPA将能够与AEM及其内容创作功能一起发挥作用。
如果您在开发SPA时牢记这些原则,它将尽可能灵活和将来验证,同时启用所有受支持的AEM创作功能。
如果您不需要支持AEM创作功能,则可能需要考虑不同的SPA设计模型。
与开发任何组件一样,您的组件的设计方式应最大限度地提高其可移植性。 任何与组件的可移植性或可重用性相抵触的模式都应避免,以确保今后的兼容性、灵活性和可维护性。
最终的SPA应使用高度可移植和重用的组件构建。
前端开发人员必须认为自己负责创建用于构建应用程序的SPA组件库。 前端开发者完全控制组件的内部结构。 但AEM始终拥有该站点的结构。
这意味着前端开发人员可以在组件入口点之前或之后添加客户内容,还可以在组件内进行第三方呼叫。 但是,前端开发人员并不完全控制组件的嵌套方式,例如。
SPA只应依赖内容的动态呈现。 这是AEM获取和呈现内容结构的所有子级的默认期望。
任何指向特定内容的显式渲染均视为静态渲染,尽管受支持,但与AEM内容创作功能不兼容。 这也违背了可移植性的原则。
与渲染一样,所有路由也应是动态的。 在AEM中,SPA应始终拥有路由并AEM监听它并基于它获取内容。
任何静态路由均与可移植性原则相抵触,并且与AEM的内容创作功能不兼容,从而限制了作者。 例如,使用静态路由时,如果内容作者希望更改路由或更改页面,则他/她必须要求前端开发人员完成此操作。
任何AEM项目都应利用AEM项目原型,它支持使用React或Angular的SPA项目并利用SPA SDK。
如果遵循在AEM中开发SPA的原则,则您的SPA将可以与所有支持的AEM内容创作功能一起使用。
然而,在有些情况下,这并非完全必要。 下表概述了各种设计模型、它们的优点和缺点。
设计模型 |
优势 | 缺点 |
---|---|---|
AEM用作无外设CMS,而不使用SPA编辑器SDK框架。 | 前端开发人员完全控制应用程序。 | 内容作者无法利用AEM内容创作体验。 如果代码包含静态引用或路由,则它既不可移植,也不可重用。 不允许使用模板编辑器,因此前端开发人员必须通过JCR维护可编辑的模板。 |
前端开发人员使用SPA Editor SDK框架,但只向内容作者打开部分区域。 | 开发人员只在应用程序的受限区域中启用创作,从而保持对应用程序的控制。 | 内容作者仅限于有限的AEM内容创作体验集。 如果代码包含静态引用或路由,则它既不可移植,也不可重用。 不允许使用模板编辑器,因此前端开发人员必须通过JCR维护可编辑的模板。 |
项目完全利用SPA Editor SDK,前端组件作为库进行开发,应用程序的内容结构委托给AEM。 | 该应用程序可重用、可移植。 内容作者可以使用AEM内容创作体验编辑应用程序。 SPA与模板编辑器兼容。 |
开发人员无法控制应用程序的结构以及委派给AEM的内容部分。 开发人员仍然可以为不打算使用AEM创作的内容保留应用程序的区域。 |
尽管AEM支持所有模型,但只有通过实施第三种模式(并因此遵循AEM<a](#spa-development-principles-for-aem)中建议的[SPA开发原则),内容作者才能与SPA中的内容进行交互并编辑它们习惯的内容。
通常,如果SPA遵循AEM的SPA开发原则,则SPA将在AEM中工作,并可使用AEM编辑器进行编辑。
按照以下步骤操作,使现有SPA可以与AEM一起使用。
让前端开发人员创建AEM的主要任务是同意组件及其JSON模型。
下面概述了前端开发人员在开发SPA for AEM时需要遵循的步骤。
同意组件及其JSON模型
前端开发人员和后端AEM开发人员需要商定哪些组件是必需的以及一个模型,以便从SPA组件到后端组件实现一对一匹配。
AEM组件在提供编辑对话框和导出组件模型时仍然很有必要。
在React组件中,通过this.props.cqModel
在商定组件并部署JSON模型后,前端开发人员可以免费开发SPA,只需通过this.props.cqModel
访问JSON模型。
实现组件的方 render()
法
前端开发者根据自己的需要实施render()
方法,并可使用cqModel
属性的字段。 这将输出将插入页面的DOM和HTML片段。 这是在React中构建应用程序的标准方式。
通过MapTo()
映射存储组件类,并由提供的Container
组件在内部使用,以基于给定的资源类型检索和动态实例化组件。
它用作前端和后端之间的“胶水”,以便编辑者知道反应组件对应的组件。
Page
和ResponsiveGrid
是扩展基Container
的类的好示例。
将组件定义 EditConfig
为参数MapTo()
此参数是告知编辑者如何命名组件(只要尚未渲染或没有要渲染的内容)的必需参数。
为页面和 Container
容器扩展提供的类
页面和段落系统应扩展此类,以使委派到内部组件正常工作。
实施使用HTML5 API的路由解决 History
方案。
启用ModelRouter
后,调用pushState
和replaceState
函数将触发对PageModelManager
的请求,以获取模型的缺失片段。
ModelRouter
的当前版本仅支持使用指向Sling Model入口点的实际资源路径的URL。 它不支持使用虚URL或别名。
可以禁用ModelRouter
或将<a0/>配置为忽略常规列表。
这些代码块说明您的React和Angular组件如何不需要特定于Adobe或AEM的任何内容。
MapTo
帮助程序是允许后端和前端组件相匹配的“粘合剂”:
有关一般使用MapTo
和构建SPA for AEM的详细信息,请参阅所选框架的入门指南。
AEM的一般架构(包括开发、创作和发布环境)在使用SPA时不会发生变化。 但是,了解SPA开发如何适合此体系架构是有帮助的。
构建环境
这是检出SPA应用程序源和组件源的源的位置。
AEM Author
内容是在AEM作者(包括创作SPA)上创建的。
当SPA在创作环境中使用SPA编辑器进行编辑时:
cq-data
属性。cq-data
属性允许编辑器加载其他页面信息,以便它知道组件可以使用哪些编辑配置。AEM 发布
这是创作内容和编译库(包括SPA应用程序对象、clientlibs和组件)的发布位置,用于公开使用。
调度程序/CDN
调度程序充当AEM的缓存层,访客到站点。
在AEM中,无需执行Javascript构建机制或执行Javascript本身。 AEM仅托管SPA应用程序中的已编译对象。