云客Drupal源码分析之主题协商theme negotiator

本文主要是介绍云客Drupal源码分析之主题协商theme negotiator，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

drupal主题系统十分灵活，你可以全站使用一套主题，用响应式设计去兼容移动端和pc端，如果响应式无法满足要求，你可以在各端分别使用不同的主题，但其灵活性远不止如此，实际上在同一个站点中你可以根据任意条件使用不同的主题，系统后台设定的只是默认值而已，比如在pc端或移动端你可以为不同语言采用不同主题，甚至不同用户采用不同模板，条件是任意的，只需要简单实现一个主题协商即可，这就是本篇所讲的内容。

在drupal中我们可以安装多个主题，前端和管理界面可以各自指定一个默认主题（前端默认为bartik，管理界面为seven），但并不意味着只能使用被指定的默认主题，在站点中可以同时使用多个主题，只要她们被安装了，那么一个页面应该使用哪个主题呢？决定一个页面使用什么主题是由主题协商者完成的，她是系统定义的一个服务，实际上系统中有许多个主题协商者，她们按优先级排序形成一个队列，依次执行，一旦有协商者做出决定那么将忽略后续协商者，模块可以自定义主题协商者，在其中我们可以通过任意条件指定任意页面的主题，比如前文提到的pc端和移动端分别开发主题时，我们就可以根据浏览器的代理标志来判断使用哪个主题。

注意：这里需要注意主题和模板之间的区别，可以简单的这样理解：主题是一套模板的集合，从系统角度看一个主题是一个扩展，除了模板还有很多函数、js、css等等；主题协商是在主题选择层面工作的，在一个主题内使用哪个模板那是模板钩子建议的事情（本系列其他文章介绍），一个主题内所有页面模板风格应该是一致的，不同主题风格往往不同，这不是一个概念。

自定义主题协商者：
这就是在定义一个服务，先定义一个类，放置在名字空间对应的文件中，该类必须实现以下接口：
\Drupal\Core\Theme\ThemeNegotiatorInterface
该接口有两个方法：
applies(RouteMatchInterface $route_match)：
根据情况决定是否需要使用本协商者，返回布尔值，如果返回fasle那么主题协商的工作将交由随后的主题协商者来完成，系统默认会传递当前主请求的路由匹配器对象，但该方法内部我们也可以根据其他信息来做决定
determineActiveTheme(RouteMatchInterface $route_match)：
返回主题的机器名（注意是机器名），也可以返回NULL表示协商失败，这将使协商工作让给优先级低的随后主题协商者

注意：在主题协商者中我们无需实现对主题的权限检查，该工作将由“access_check.theme”服务去完成（见后文）。

定义好类后，在MODULE.services.yml中将她声明为服务，见下，重点是给出“theme_negotiator”标签和优先级属性，在容器编译阶段系统会自动收集她并按照优先级排序。

系统提供的主题协商者：
系统默认提供了六个主题协商者，可以参考她们的服务定义和实现，以下是按照优先级从高到底排序：
ajax基本页：
基于POST变量中的ajax_page_state变量，她是一个数组，键名含'theme'（主题机器名）和'theme_token'（验证令牌），只要令牌正确将使用'theme'指定的主题，服务定义如下：

  theme.negotiator.ajax_base_page:class: Drupal\Core\Theme\AjaxBasePageNegotiatorarguments: ['@csrf_token', '@config.factory', '@request_stack']tags:- { name: theme_negotiator, priority: 1000 }

块管理demo页：
只针对“block.admin_demo”路由，采用该路由中路由参数'theme'指定的主题，服务定义如下：

  theme.negotiator.block.admin_demo:class: Drupal\block\Theme\AdminDemoNegotiatortags:- { name: theme_negotiator, priority: 1000 }

系统批处理页面：
只针对“system.batch_page”路由，服务定义如下：

  theme.negotiator.system.batch:class: Drupal\system\Theme\BatchNegotiatorarguments: ['@batch.storage', '@request_stack']tags:- { name: theme_negotiator, priority: 1000 }

系统数据库更新页：
只针对'system.db_update'路由，用于数据库维护更新时使用，可以在站点配置文件中使用配置项“maintenance_theme”指定一个主题，如没有设定该配置项将采用'seven'，如果设置为false将使用默认前端主题，服务定义如下：

  theme.negotiator.system.db_update:class: Drupal\system\Theme\DbUpdateNegotiatorarguments: ['@config.factory']tags:- { name: theme_negotiator, priority: 100 }

管理（后端）页主题：
用户有'view the administration theme'权限，且访问的是管理页（路由中有'_admin_route'选项），那么将使用管理主题，服务定义如下：

  theme.negotiator.admin_theme:class: Drupal\user\Theme\AdminNegotiatorarguments: ['@current_user', '@config.factory', '@entity.manager', '@router.admin_context']tags:- { name: theme_negotiator, priority: -40 }

默认主题：
这是优先级最低的协商者，如果没有其他协商者进行有效协商时总是被使用，她总是返回前端默认主题，服务定义如下：

  theme.negotiator.default:class: Drupal\Core\Theme\DefaultNegotiatorarguments: ['@config.factory']tags:- { name: theme_negotiator, priority: -100 }

通过以上系统提供的六个默认协商者，可以看到最高的优先级是1000，默认协商者优先级最低，为-100，我们自定义的协商者优先级需要参考她们以进行恰当的排序，当高优先级作出有效协商后，低优先级将被忽略，最低不能低于-100，否则将使用默认主题。
比如前文提到的选择pc端和移动端主题的协商者就可以定义在-40到-100之间，这样管理界面不受影响，前端将在各端使用不同主题。

代理协商者：
在系统中对所有协商者的应用是在一个代理中完成的，她的服定义如下：
服务id：theme.negotiator
类：\Drupal\Core\Theme\ThemeNegotiator
在其中可以看到优先级的处理逻辑，她执行了主题访问检查。

主题访问检查：
服务id：access_check.theme
类：Drupal\Core\Theme\ThemeAccessCheck
默认检查仅仅是基于主题是否被安装，如果还没有被安装那么不允许使用。如有需要，我们可以在模块中定义自己的服务去覆写该访问检查器以实现高级特殊的检查。