61.渲染管道及显示变体DisplayVariant 你一定好奇为什么控制器只返回了很简单的渲染数组,简单到甚至里面只包含了一个字符串标签而已,可最后的页面为何包含了那么多信息(页头、页尾、侧边栏、搜索框、导航菜单、面包屑路径等等)?是多次执行请求流程再合并结果吗?本主题讲解关键的渲染过程,将回答这些问题。通过本系列前面的学习你现在已经知道了drupal程序部分的主体结构,从本篇开始将越来越多的涉及到看的见的部分:页面外观。
59. 内容实体储存模式处理EntityStorageSchema 一个实体类型创建后,在她的生命周期中,她和她的字段定义可能出现更新、删除操作以满足业务需求,而不是一旦创建就不能被改变,所以要求她的储存Schema是动态的,在发生这样的事情时需要作出反应,典型的就是数据库schema
58. 实体entity(六)内容实体储存处理器类 内容实体储存处理器类,顾名思义就是解决内容实体的储存问题,这主要有两大块内容:实体数据从储存后端的读写,这个过程需要派发钩子让模块参与进来;实体储存后端的管理,也就是schema的增删改,先有这才能进行数据存取
57. 内容实体数据库表结构及表映射table mapping 在drupal中提到“字段”这个概念时,请不要理解为数据库中表的一个列,这不是一个概念,它是指一个字段对象,充当着实体对象的属性,也是一个列表类型的类型化数据对象,当本系列提到“字段field”一般均是指字段对象或字段定义对象,而数据库表中的字段列,则将其称为“列column”
56. 实体字段管理器entity_field.manager 实体字段管理器用于获取和实体类型有关的字段信息,她让各模块参与建设实体类型的字段定义,是所有内容实体类型的字段定义中枢,在涉及实体字段信息时大多会用到她,比如节点实体储存处理器用它来确定数据库表信息,因此很重要,以下讲述她的各种方法: 容器服务id:entity_field.manager
55. 字段API(下) 一个可字段化的实体类型自身定义的字段称为基本字段(非bundle定义,模块可以通过钩子entity_base_field_info添加定义),她们存在于所有的bundle中,也就是说所有bundle可用,基本字段定义可以通过模块的
54. 实体类型bundle信息服务entity_type.bundle.info 实体类型bundle信息服务在容器中的服务id是entity_type.bundle.info,从代码上说这是一个很简单的服务,用以获取系统中实体类型的bundle信息,由于她充分的展示了什么是bundle,进一步帮助理解bundle这个概念,因此本系列将她作为一个独立主题来讲述。 服务id:entity_type.bundle.info
53. 实体Entity(五)内容实体基类 源码分析重点在于在自己的大脑中重现开发者的思维过程,内容实体基类是drupal中很大的一个类,她要处理众多的问题,内容实体的大多数功能都集中在这里,开发者有许多的考虑,要弄清楚她的所有细节,学习者可能会觉得有些困难,这时需要明白任何复杂庞大的事物都是一步步累积发展起来的,初遇的学习者只看到了她的结果,没有看到她的演化历程,所以有这样的感觉很正常,开发者也不是一步到位的,而是从简单到复杂、反复
52. 字段API(中) 字段api的核心为字段对象、字段控件、字段格式化器,在上节中已经强调了字段对象中的字段含义不等于数据库层面的字段(数据表中的列),她是更高一级的抽象,字段对象是一个列表型的类型化数据对象,附属到实体对象作为属性,列表中的每一个条目是一个复合类型的类型化数据对象,可以叫做字段条目对象,字段对象是列表对象决定着字段可以是多值的,这也就是为什么我们在管理后台字段管理中可以设定数量限制的原因,字段条