当前位置: 首页>>技术解读>>正文


对于当前的D8状态,创建新的内容实体类型与为“节点”内容实体创建内容类型的决策树是什么?

webfans 技术解读 , , 去评论

问题描述

自从接受的答案是针对“When is it appropriate to create an Entity versus just adding a new content type?而且,实体对Drupal 8的重要性比在Drupal 7中更为重要。(RefBRefCRefD)

在这个新的Drupal 8世界中,为”Node”类型的内容实体创建新内容实体类型与新内容类型的决策树是什么?

在考虑回复时,请考虑以下事项:

  • 内容实体类型”Node”的新内容类型是否仍然适用于99%的情况而不是新的内容实体类型?

  • 决策树现在是否包含更多,更好或更明确的理由,以避免使用”Node”内容实体类型而是创建新的内容实体类型?如果是的话,他们是什么?它们包括:

    • 性能?

    • 安全/权限?

    • 使用Node-entity-type Content-Types并且不能与其他内容实体类型一起使用的模块数量?

  • 也许 – 基于上面引用的先前接受的答案 – 进行自定义内容实体类型的唯一一般原因是,如果要对节点数据进行分组,例如,使用分类术语或以其他方式注释节点,例如有评论?

模块兼容性似乎是决策树的一个特别有趣的考虑因素。目前,很少有most-installed modules有8.x版本,不仅仅是alpha,beta或rc(发布候选版本)。并且似乎很难确定其中有多少将使用新的自定义实体类型与新的Node-entity内容类型一起使用out-of-the-box。似乎没有项目属性来区分“为实体编写”与“为节点实体内容类型编写”的属性。

看一下pathauto,它是目前fourth-most安装的那些具有任何8.x版本的模块。在8.x版本上,人们是working hard,它通常支持实体而不仅仅是Node-entity-type内容类型。但是所有其他模块呢?并且支持实体的模块通常需要自定义内容实体类型才能在模块使用之前使用module-specific “hooks”吗? (对战如何模块可能只是直接制定出新的内容类型的箱子?)That appears to be那种pathauto团队正在与挑战,或许这是有原因的改变方向从一个自定义内容实体类型了吗?

值得一提的是,Drupal 8核心包含用于为”Node”类型的内容实体创建新内容类型的UI,但它目前不包含用于创建新内容实体类型的UI。 (RefXRefYRefZ)

最佳解决方案

用于在创建新Node-entity-type内容类型与新内容实体类型之间进行选择的决策树:

  1. 你是程序员吗,还是你可以轻松访问程序员?

    • 如果不是,那么您目前pretty-much仅限于创建新的Node-entity内容类型。 (核心中没有用于创建新内容实体类型的UI,而Entity Construction Kit (ECK) contrib模块目前只有alpha版本。)

    • 如果是,那么继续……

  2. 您是否确切知道要为您的数据利用哪个contrib modules

    • 如果不是,那么安全的赌注可能只是创建一个Node-entity内容类型。

    • 如果是,那些模块是否已经支持您正在考虑的自定义实体类型,或者您是否愿意帮助增强它们以便在模块中重新创建所需的功能?

      • 如果不是,那么只创建一个Node-entity-type内容类型可能最适合您。

      • 如果是,那么继续……

  3. 您的模块启用的实际内容数据是否仅仅有助于对其他内容数据进行分组或注释? (因此很少能单独查看。)

    • 如果是,则考虑您的模块是否与分类术语和注释的现有实体类型相似。如果是,那么新的实体类型可能是安全的赌注。

    • 如果没有,那么继续……

  4. 您能清楚地阐明为什么新的Node-entity-type内容类型不适合您吗?

    • 如果不是,那么您的安全赌注可能只是创建一个新的Node-entity-type内容类型。

    • 如果是,那么继续……

  5. 最后,您确定不能只扩展Node-entity-type并且您想要重新创建其所有有用的功能,如CRUD操作吗?

    • 如果是,则继续创建新的自定义实体类型。

    • 如果不是,或者您不确定,那么您可能希望聘请一些专家来帮助您做出决定。

笔记:

  1. 此决策树不考虑性能或安全性。我不确定新的自定义内容实体类型是否或何时会比Node-entity-type更好或更安全。

  2. 即使这个树是一个很好的答案,由于Drupal核心和contrib模块版本的更新,它可能不会随着时间的推移而保留。 StackExchange似乎不适应今天的”best”答案可能不是明天的最佳答案。)

次佳解决方案

关于该问题的一个简单方法是考虑项目目的,规模和业务要求。

  1. 默认node-entity内容类型如何以一种简单,整洁的方式影响构建项目,更接近于从项目文档的分析思维产生的体系结构和数据流。

这里的一个重要注意事项创建新实体类型的决定通常由开发人员或技术主管承担,而不是管理应用程序且仅关注业务的站点构建者或项目所有者。

  1. Drupal 8依赖于一些symfony2软件包并且更接近框架,开发传统cms谈论Drupal与大型体系结构的变化,我认为构建一个新实体比在node-entity内容类型上进行许多自定义和复杂配置要好,以便利用Drupal和其他框架一样,因为许多人不喜欢Drupal配置和分布式设置的方式,你可能会遇到一些人来自WordPress,并且习惯于从一种形式配置所有东西,这使得他们在处理Drupal管理仪表板时感到恼火。

  2. Drupal 9计划完全删除钩子系统并替换为事件调度器,这导致需要管理界面来创建新实体,因为从代码中改变现有功能对于非开发人员而言将非常困难添加该功能。

最后,我看到针对项目需求量身定制的新实体比具有大量字段的复杂内容类型更好地提供高性能,因为我们现在每个字段向数据库添加2个表,并且需要在每个请求上加载其配置,尤其是在需要繁重的业务逻辑。

第三种解决方案

简单明了:并非所有内容都是如此。如果您只是使用内容类型,内容列表可能会很长并且会令人困惑。 (ContentEntityBase也可以由自定义实体thoe实现)

If you have an author and published state you should go for a content type.


否则(假设你的程序员)自定义实体应该是首选。所有接口都可以轻松实现很多(如revision-able,field-able,访问限制等)

In my view this is just clearer and tail-ordered architecture (and also more performant).

考虑到几个项目的可重用性,使得自定义实体的爆发……还有像drupal-code-generator这样的漂亮助手。要将自定义编码(或复杂性)保持在较低级别,您应该考虑使用内容类型:

  • 要翻译’entity'(至少在D7中),还会有一个接口。

  • (打开建议)..

第四种方案

这是一个棘手的问题,诚实地说,我认为只有在您之前实施之后才能理解。但正如雷米所提到的,并非一切都是原始的,面向用户的内容。

在Drupal 7中,存在创建自定义实体的功能,但如果你在OOP的边粗糙,则可能是一项艰巨的任务。它有点半实现(或者半成品,但是你想说它),这导致了创建不完全统一和商定方法的实体的方法,混合程序和混合OOP。

在Drupal 8中,这个想法得到了更多的实现,并且使用自定义实体启动和运行起来要容易得多。节点本身基于ContentEntityBase,Block,Users,File和Taxonomy也是如此。

节点专门用于发布的,可见的(或授权的)内容数据,这些数据通常用作内容(即在菜单中,或在站点Map中,或xml站点Map或RSS源等)。 Drupal的设计方式是,您可以挂接到节点操作过程的任何步骤并更改它,如果您有错误的贡献模块组合,可能会产生意想不到的后果。这可能是一个有争议的观点,但它有助于将自己与“一切都是节点”的想法分开,以便更多地接受实体概念。

制作精彩内容类型的理想内容:

  • 文章

  • 招聘启事

  • 事件

  • 登陆页面

  • 主页

他们的共同点是他们共享一种内容的概念。它通常处于任意数量的工作流状态(发布,升级,粘性,存档,特色等 – 如果您使用自定义发布选项),并且大量贡献的模块直接与其交互,如Pathauto。

但是我们假设您希望将数据存储在Drupal中,该数据是内部的,私有的,驱动其他数据,或者除非您允许,否则不应允许在其范围之外进行集成的数据。这可能是什么样的数据?以下是一些可能的类型:

  • 产品(Drupal Commerce)

  • 订单项(Drupal Commerce)

  • 搜索服务器(ApacheSolr /SearchAPI)

  • 联系方式(如CRM主管)

  • 门票(如支持票)

是什么让这些如此不同?为什么您需要实体进行联系,而不是使用用户模型?你可以在那里做一些论点,但我的例子是,如果你说,从联系表单收集电子邮件地址和名称以及一些其他元数据,将这些数据存储为自定义实体。您可以防止用户列表被non-account项目污染,减少潜在的安全问题(如果脚本或某人不小心将这些帐户更新为管理员或发送群发邮件怎么办?),您可以更轻松地对实际用户帐户进行内部管理,并将您捕获的内容细分为一个特定的数据位。

从这里开始,它与Drupal /Node系统中更自动化的部分基本分离,您可以定制操作和体验。您可以确定路由,访问和CRUD工作流程。

在这种思维模式中,它可以更容易地查看为什么这样做的方法将以这种方式完成。以支持票证为例 – 它是传入的请求,但不是已发布的数据,并且可能有一个非常特定的工作流程,更容易设置自己的方式,而不是将它与您不希望它遵守的节点系统部分分开至。

另一个例子是外部导入数据。在大多数情况下,这些数据通常不会使用本地Drupal数据(即使它是一个实体,你仍然可以这样做)。它可能是任何东西。也许它是发票,也许它们是书籍,也许是拉啤酒的品牌。

像这样的数据通常是特定的,需要超出节点的控制范围。这并不是说你不能通过使用节点上的引用字段来指向你的自定义实体(这就是Drupal Commerce在某种程度上工作的方式)来丰富数据。同时,您正在隔离并确保从错误的贡献代码中控制您的数据和UI,超出其设计范围并干扰您的模型。这在D8中可能不像在D7中那么严重,尽管有些钩子仍然存在。

现在存在适当的架构以鼓励分离。并非一切都是节点。

参考资料

本文由朵颐IT整理自网络, 文章地址: https://duoyit.com/article/2087.html,转载请务必附带本地址声明。