Origine du moteur de modèles
Au début du développement PHP des applications WEB, le code PHP et les modèles HTML étaient mélangés. La naissance des moteurs de modèles visait principalement à résoudre le problème de la séparation complète du back-end et du front-end (maintenant c'est le cas). semble qu'il s'agisse en fait d'une séparation incomplète). Cela permet aux développeurs et aux artistes de travailler ensemble (même si en fait la plupart du travail final sur les modèles est toujours effectué par les développeurs back-end), améliorant ainsi l'efficacité du développement et facilitant la maintenance.
Avec la croissance rapide de PHP, il existe de plus en plus de moteurs de modèles, mais ils sont grossièrement divisés en deux types : interprétés et compilés. La plupart des moteurs de modèles traditionnels actuels sont compilés, c'est-à-dire qu'ils seront d'abord compilés. Le modèle est compilé dans un fichier PHP pour exécution. Tant que le fichier modèle lui-même ne change pas, il n'est pas nécessaire de le recompiler, comme l'ancien Smarty. Un moteur de modèle interprété effectuera un processus d'analyse de modèle à chaque fois qu'il est exécuté, comme tinybutstrong.
ThinkPHP a intégré dès le début un moteur de modèles compilé basé sur la technologie de bibliothèque de balises XML. Il a été référencé dès le début à partir de Struts et évolue constamment en absorbant de nouvelles idées.
Comment choisir un moteur de modèles
Actuellement, les frameworks grand public ont des composants de moteur de modèles ou encapsulent l'implémentation de moteurs de modèles, alors choisissez des moteurs de modèles intégrés solutions La solution est le meilleur choix, avec une fonctionnalité et une stabilité garanties. Actuellement, les moteurs de modèles les plus populaires sont le moteur de modèles Blade de Laravel et le moteur de modèles Twig de Symfony.
En installant l'extension du moteur de modèles, vous pouvez facilement utiliser des moteurs de modèles, notamment Angular, Twig et Blade dans ThinkPHP, ou même utiliser des fichiers PHP directement comme modèles sans utiliser de moteur de modèles du tout.
En raison de la popularité des trois principaux frameworks front-end (React/Vue/Angular) ces dernières années, le développement séparé du front-end et du back-end est progressivement devenu courant. Par conséquent, ThinkPHP5.0 est devenu courant. a été positionné pour le développement d'API, ce qui a conduit à un affaiblissement du concept de moteur de modèles. Le moteur de modèles de ThinkPHP version 5.1 a subi une reconstruction interne, rendant les balises de modèles plus faciles à utiliser et plus proches de la syntaxe PHP.
Au moins pour la plupart des nouvelles applications, vous devriez choisir une conception de séparation front-end et back-end plus courante afin de réduire autant que possible la pression sur le serveur et de faciliter les tests des front-end et back-end. séparément. Vous verrez par inadvertance des produits utilisant Vue et ThinkPHP sur le marché (les numéros précédents de ThinkPHP Developer Weekly en ont fait état de plusieurs). Si vous gérez certains anciens projets, notamment des produits de gestion de contenu, vous pouvez toujours utiliser des moteurs de modèles.
Compte tenu de cette situation, la prochaine version du framework ThinkPHP n'aura pas de moteur de modèle intégré, mais les développeurs qui ont besoin d'utiliser le moteur de modèle peuvent toujours utiliser la bibliothèque de classes think-template indépendante officielle. Pour une utilisation spécifique, veuillez vous référer à cet article.
Dans les sections suivantes, nous résumerons principalement l'utilisation et les techniques du moteur de modèles intégré de ThinkPHP.
Processus d'exécution du modèle
La relation d'appel du moteur de modèle au sein du système est la suivante :
Voir ( View) < ;=> Pilote de modèle (Pilote) <=> Moteur de modèle (Modèle)
Une couche de pilote est ajoutée entre la vue et le moteur de modèle, afin qu'il puisse facilement remplacer d'autres moteurs de modèles . Habituellement, les méthodes assign/fetch et autres que nous appelons dans le contrôleur sont en fait les méthodes de la classe thinkView appelée. Bien sûr, si nécessaire, vous pouvez également utiliser directement la classe du moteur de modèle dans le contrôleur, mais il n'est pas pratique de passer à d'autres moteurs de modèle.
Prenons la méthode fetch comme exemple. Jetons un coup d'œil au processus d'appel final :
think\Controller->fetch(); think\View->fetch(); think\view\driver\Think->fetch(); think\Template->fetch();
Si vous ne transmettez pas le nom complet du fichier modèle à restituer lorsque vous appelez la récupération. méthode, il sera affiché dans la troisième. Identifiez automatiquement le fichier modèle à restituer au cours de l'étape.
Évidemment, l'étape la plus critique est la dernière étape. Le processus de compilation et d'exécution du modèle est entièrement complété par la méthode
think\Template->fetch();
. Ce lien peut être grossièrement divisé en plusieurs processus.
1. Déterminez et lisez le cache de rendu de page
Si le modèle actuel a un cache de sortie de page défini et a été rendu et affiché, si c'est le cas, le cache le fera. être lu Le contenu de sortie est directement sorti.
if (!empty($this->config['cache_id']) && $this->config['display_cache']) { // 读取渲染缓存 $cacheContent = $cache->get($this->config['cache_id']); if (false !== $cacheContent) { echo $cacheContent; return; } }
2. Localisez le fichier modèle
L'opération de positionnement du fichier modèle est en fait implémentée par la méthode parseTemplateFile de la classe du moteur de modèle. identique au parseTemplate de la classe du pilote de vue. La méthode est similaire, si le fichier modèle final n'existe pas, une exception n'existe pas sera levée.
$template = $this->parseTemplateFile($template);
3. Déterminez le cache de compilation
Si le fichier modèle actuel a été compilé, il déterminera si le cache est toujours valide. S'il est valide, là. Il n'est pas nécessaire de répéter l'analyse et de lire directement le contenu de l'analyse du cache. Cela se fait par la méthode checkCache.
if (!$this->checkCache($cacheFile)) { // 缓存无效 重新模板编译 $content = file_get_contents($template); $this->compiler($content, $cacheFile); }
4. Compilation et mise en cache de modèles
这一步骤是模板引擎最核心的环节,也是功能最复杂的地方,由compiler方法负责完成,主要是解析当前模板文件中的模板标签语法为PHP可执行代码,然后生成一个模板解析缓存文件,也就是所谓的模板“编译”,其中使用了大量的正则表达式替换技术,虽然正则解析有一定的性能开销,但得益于一次解析多次调用的缓存原理,基本上模板解析的性能开销不会影响实际使用的性能。
模板编译方法的关键代码是parse方法,parse方法负责对模板文件中的标签进行解析,然后写入编译缓存文件,编译缓存默认使用的是文件缓存,支持扩展。
5、读取编译缓存
模板编译的过程只是生成了模板编译缓存文件,并没有真正载入模板,这一步骤就是载入模板编译缓存,然后导入模板变量。实现方法可以参考think\template\driver\File类的read方法。
public function read($cacheFile, $vars = []) { $this->cacheFile = $cacheFile; if (!empty($vars) && is_array($vars)) { // 模板阵列变量分解成为独立变量 extract($vars, EXTR_OVERWRITE); } //载入模版缓存文件 include $this->cacheFile; }
6、缓存页面输出
如果当前模板渲染的时候开启了页面输出缓存,就会这一步生成页面渲染后的输出缓存。
模板编译原理
我们来了解下ThinkPHP的模板引擎的实现原理。前面提到过,ThinkPHP的模板引擎最早源于Struts的设计理念,基于XML和标签库的技术实现。在设计模板语言的时候使用系统固定的标签来实现普通的变量输出功能(所以称之为普通标签),而利用XML标签库技术实现的动态标签用于变量的控制或者条件判断输出。
普通标签的解析是由think\Template类的parseTag方法完成的,主要实现了下面几个模板功能:
·变量输出(包括系统变量);
·函数过滤;
·变量运算;
·三元运算;
·执行函数以及输出结果;
·模板注释。
标签库采用的是动态扩展的设计方案,采用了类似XML的闭合/开放定义方式(这个其实也是目前模板引擎的一个局限所在),例如下面的这个:
// 闭合类型标签 <tagLib:tagName name="value" > ... </tagLib:tagName> // 开放类型标签 <tagLib:tagName name="value" />
tagLib就代表了一个标签库(类),后面的tagName标签就表示该标签库下面的某个标签(通常对应了标签库类的某个方法),后面的属性就是该标签支持的属性定义。具体该标签的属性和功能则完全由标签库类的这个方法来决定。
可以在模板开头明确指出,当前模板使用了哪些标签库
{taglib name="html,article" /}
所以要扩展模板引擎的功能只需要通过扩展一个标签库类就可以了。大多数的内容管理系统都会定义一套自己的模板二次开发标签,利用标签库功能就可以很方便的定义一套属于自己的标签功能。
系统内置了一套标签库Cx,主要用于文件包含、条件控制、循环输出等功能。内置标签库在使用的时候无需引入,而且在使用的时候可以省略标签库前缀,例如:
{foreach $list as $key=>$vo } {$vo.id}:{$vo.name} {/foreach}
这个模板语法相信PHP开发的很容易上手,上面的标签解析由think\template\taglib\Cx类的tagForeach方法完成,该方法的返回值是一个字符串,其实就是最终会解析成的一段包含变量的PHP可执行代码。
到这里,模板引擎的执行过程和原理现在基本就明白了,剩下的就是模板标签的解析细节,考验的就是正则表达式的掌握程度了。本文就不做深入了,有兴趣的朋友可以去看一些正则表达式的相关资料(例如这本《正则指引》,开发者周刊第14期也提供了一些在线的正则工具)。
遵循的原则
使用模板引擎,要尽量遵循几个重要的原则。
不要在模板文件中添加任何的业务逻辑
模板的作用主要是进行模板变量的控制和输出,不要在模板文件中添加业务逻辑代码。
明确指定渲染模板
养成明确指定渲染模板的好习惯,避免当方法名发生变化,或者被其它方法调用的时候发生错误。也不易受模板命名规范的影响。
变量统一赋值
使用assign方法或者在view助手函数的时候,统一一次传入模板变量。不要多次赋值,以免混乱。
系统变量无需赋值到模板
对于系统变量(包括请求变量、$_SESSION和$_SERVER等系统变量)无需进行模板变量赋值,可以直接在模板中输出。
常见问题
这里总结一下经常会遇到的一些常见问题。
修改定界符
可以通过模板配置文件修改模板标签的定界符。
例如,修改普通标签定界符
'tpl_begin' => '{{', // 模板引擎普通标签开始标记 'tpl_end' => '}}', // 模板引擎普通标签结束标记
标签库标签定界符
'taglib_begin' => '<{', // 标签库标签开始标记 'taglib_end' => '}>', // 标签库标签结束标记
保持原样输出
如果担心模板标签和JS代码产生混淆,可以使用literal标签
{literal} Hello,{$name}! {/literal}
页面最终会直接输出
Hello,{$name}!
避免输出转义
5.1版本为了避免XSS攻击,默认对模板变量的输出使用了安全转义,默认的转义函数是htmlentities,你可以通过更改default_filter配置改变默认的转义函数。
如果你不需要对某个模板变量输出进行转义(例如包含了HTML代码),可以使用:
{$data.content|raw}
分页输出就是一个需要输出HTML的典型例子,因此必须增加|raw。
关于模板主题
新版取消了原来的模板主题功能,因为模板主题对模板引擎来说,其实无非是一个模板目录,完全可以根据自己的需求控制。
例如
$theme = 'blue'; $this->fetch('/' . $theme. '/user/index');
或者动态设置模板引擎的view_path参数
$this->view->config('view_path', \think\facade\App::getModulePath(). 'view/'. $theme . '/');
如何关闭模板缓存
由于是编译型模板引擎,模板标签不能被直接执行,必须编译成PHP语法后才能执行,因此不能关闭模板编译缓存,模板引擎每次执行渲染的时候会检测模板文件是否有变化,当模板文件的修改时间超过模板编译缓存的修改时间后,模板引擎会自动更新编译缓存。
但你可以强制模板引擎每次都重新编译,只需要在配置文件中设置
'tpl_cache' => false, // 关闭模板缓存
使用PHP作为模板引擎
如果不希望使用内置的模板引擎,直接使用PHP作为模板引擎,可以配置
'type' => 'php',
配置使用PHP作为模板引擎的话,是不会生成模板编译缓存的。
如何使用第三方模板引擎
系统支持扩展其它的第三方模板引擎,你只需要开发一个模板引擎驱动,目前已经支持的第三方模板引擎包括Smarty、Twig和Blade。
如何跨模块输出模板
要渲染一个跨模块的模板文件,你需要使用
// 渲染user模块的模板文件 $this->fetch('User@order/index');
是否支持变量运算
可以直接在模板文件中进行变量运算而不需要在控制器中进行运算后再赋值都模板变量输出。
{$score1+$score2} {$count++}
文件包含是否支持变量
include标签可以支持传入变量,但只能使用
{include file="$file" /}
而不能使用
{include file="file_$name" /}
可以支持模板输出替换么
支持两个方式对模板进行输出替换,如果需要对模板文件的内容进行替换,可以配置:
'tpl_replace_string' => [ '__STATIC__'=>'/static', '__JS__' => '/static/javascript', ]
如果是对模板渲染输出的内容进行替换,可以在控制器中使用视图过滤功能:
public function index() { // 使用视图输出过滤 return $this->filter(function($content){ return str_replace("\r\n",'<br/>',$content); })->fetch(); }
模板继承的block是否支持嵌套
目前模板继承的block无法支持嵌套功能,你应该使用其它方式解决。
众多ThinkPHP入门教程,尽在PHP中文网,欢迎在线学习!
本文转自:https://blog.thinkphp.cn/902998
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!