本系列即将讲解表单API，那是重要的用户交互组件，在此前有必要讲解一些系统安全相关的问题，为后续的表单API主题打下基础。

你一定好奇为什么控制器只返回了很简单的渲染数组，简单到甚至里面只包含了一个字符串标签而已，可最后的页面为何包含了那么多信息（页头、页尾、侧边栏、搜索框、导航菜单、面包屑路径等等）？是多次执行请求流程再合并结果吗？本主题讲解关键的渲染过程，将回答这些问题。通过本系列前面的学习你现在已经知道了drupal程序部分的主体结构，从本篇开始将越来越多的涉及到看的见的部分：页面外观。

通过本系列前面内容的学习你已经知道实体在数据库中是如何存储的，简单来说储存实体的数据库

实体字段管理器用于获取和实体类型有关的字段信息，她让各模块参与建设实体类型的字段定义，是所有内容实体类型的字段定义中枢，在涉及实体字段信息时大多会用到她，比如节点实体储存处理器用它来确定数据库表信息，因此很重要，以下讲述她的各种方法：
容器服务id：entity_field.manager

实体类型bundle信息服务在容器中的服务id是entity_type.bundle.info，从代码上说这是一个很简单的服务，用以获取系统中实体类型的bundle信息，由于她充分的展示了什么是bundle，进一步帮助理解bundle这个概念，因此本系列将她作为一个独立主题来讲述。

服务id：entity_type.bundle.info

源码分析重点在于在自己的大脑中重现开发者的思维过程，内容实体基类是drupal中很大的一个类，她要处理众多的问题，内容实体的大多数功能都集中在这里，开发者有许多的考虑，要弄清楚她的所有细节，学习者可能会觉得有些困难，这时需要明白任何复杂庞大的事物都是一步步累积发展起来的，初遇的学习者只看到了她的结果，没有看到她的演化历程，所以有这样的感觉很正常，开发者也不是一步到位的，而是从简单到复杂、反复

字段api的核心为字段对象、字段控件、字段格式化器，在上节中已经强调了字段对象中的字段含义不等于数据库层面的字段（数据表中的列），她是更高一级的抽象，字段对象是一个列表型的类型化数据对象，附属到实体对象作为属性，列表中的每一个条目是一个复合类型的类型化数据对象，可以叫做字段条目对象，字段对象是列表对象决定着字段可以是多值的，这也就是为什么我们在管理后台字段管理中可以设定数量限制的原因，字段条

从本质上讲，插件和钩子机制是系统各个部分传递信息和进行组织的一种机制，他们可以让各部分参与到某件事情中来，他们和事件派发器、服务定义一起形成了系统的神经系统，或称为系统总线或信息高速公路，因为插件、钩子、事件派发器、服务定义有一个共同特点：连接系统的各个部分，从而让核心和模块没有明确的边界，他们是一个整体，模块可以像核心一样参与系统建设，从而实现了drupal的高度模块化。