很多站长朋友们都不太清楚php模版引擎twig，今天小编就来给大家整理php模版引擎twig，希望对各位有所帮助，具体内容如下：
本文目录一览： 1、 golang 使用twig模板引擎，站在php的肩膀上！ 2、 smarty是什么东西，主要干什么用的 3、 Node.js代码转php 4、 为什么drupal8要选择twig作为逡 5、 thinkphp项目中怎么加载twig引擎 golang 使用twig模板引擎，站在php的肩膀上！和有些小伙伴一样，本人是从php转到了go,从事php时使用symfony框架一直享受其丰富的功能带来的便利，转到其他语言时比较直观的感觉就是twig真强，为什么其他语言没有扩展twig呢？
虽然前后端的开发模式，让模板引擎这个东西慢慢淡去，但是有时候还是需要用到这种东西，所以就有了，go调用php实现twig模板引擎的想法。
原理，go 通过exec.Command调用php,通过STDIN,STDOUT 方式进行数据交互
go在初始化阶段提供一些配置参数，比如模板引擎的为止，是否为开发环境等，php接收数据并初始化
初始换环境完毕后，当需要渲染模板，go再讲模板文件和数据以json字符串的形式写入STDIN告知php,
php接收到数据后，解析数据，选取指定的模板并渲染，然后通过STDOUT返回给go
这样一次渲染就结束了
整理好的文件打包在github上了
如果喜欢就动动你的小手指点个赞，star一下吧！
smarty是什么东西，主要干什么用的什么是smarty?
Smarty是一个使用PHP写出来的模板PHP模板引擎，由PHP.net官方提供，它提供了逻辑与外在内容的分离，简单的讲，目的就是要使用PHP程序员同美工分离,使用的程序员改变程序的逻辑内容不会影响到美工的页面设计，美工重新修改页面不会影响到程序的程序逻辑，这在多人合作的项目中显的尤为重要。
smarty优点
1. 速度：采用smarty编写的程序可以获得最大速度的提高，这一点是相对于其它的模板引擎技术而言的。
2. 编译型：采用smarty编写的程序在运行时要编译成一个非模板技术的PHP文件，这个文件采用了PHP与HTML混合的方式，在下一次访问模板时将WEB请求直接转换到这个文件中，而不再进行模板重新编译（在源程序没有改动的情况下）
3. 缓存技术：smarty选用的一种缓存技术，它可以将用户最终看到的HTML文件缓存成一个静态的HTML页，当设定smarty的cache属性为true时，在smarty设定的cachetime期内将用户的WEB请求直接转换到这个静态的HTML文件中来，这相当于调用一个静态的HTML文件。
4. 插件技术：smarty可以自定义插件。插件实际就是一些自定义的函数。
5. 模板中可以使用if/elseif/else/endif。在模板文件使用判断语句可以非常方便的对模板进行格式重排。
不适合使用smarty的地方
1. 需要实时更新的内容。例如像股票显示，它需要经常对数据进行更新，这类型的程序使用smarty会使模板处理速度变慢。
2. 小项目。小项目因为项目简单而美工与程序员兼于一人的项目，使用smarty会丧失php开发迅速的优点。
Node.js代码转php如果你们开发团队正在使用PHP，并考虑迁移到Node.js，这篇文章很适合你。本文并不探讨从PHP移植到Node.js的细节，以及Node.js的基础知识。而是涵盖：决策制定、着手点的描述、编写 Node.js 服务器的深层次注意事项、以及部署策略。
为什么迁移？
1stdibs 决定从 Apache/PHP 迁移到 Node.js+Express 有五个理由：
代码更少
全栈式JS
开发人员幸福度更高
投入回报率
未来的优化
代码更少
1stdibs基于面向服务体系架构（SAO），前端调用后台的Java服务。这意味着需要同时维护前端模型，以及服务端PHP和客户端JS模板。试想一下，如果可以摆脱PHP，就能够统一前端展现与后台模型于一种语言：JavaScript（同时可以合并一些模板）。从维护的角度来看，这么做代码更简洁，并且没有重复逻辑。
同构JavaScript万岁!
全栈式JS（及其优点）
整个开发栈使用一种语言很简便。对开发者来说，较少的环境切换使他们开心和高效。额外的好处是工具使用更简单。相比之前使用Composer和npm两个包管理器，现在只需要一个。尽管Composer很出色，由于nbp负责工具和客户端管理，nbp总是必要的。一旦去掉所有的PHP代码，nbp将成为仅有的包管理器。
开发人员乐意
我们要保证开发人员的技能集得到扩展、职业生涯不断发展，这一点很重要。对于JavaScript工程师而言，Node.js极具吸引力。能够在服务端使用与客户端相同的工具、风格和模式，是非常顺手和高效的。此外，Node.js相当流行，在企业级开发上也得到了长足发展。Node.js是JavaScript工程师的必备技能。
投入回报率
我们在招聘优秀的JS工程师和培训初级JS工程师方面花了大价钱。由于客户端栈很复杂，我们需要高级JavaScript工程师。我们不再雇用PHP工程师，仅仅雇用了JavaScript工程师。我们的观点是，为什么不培养他们在服务端的技能呢？
未来的优化
长远而言，我们打算把两个庞大的应用分割成一系列独立部署的小应用。这很容易通过Node.js、Express和nbp实现。理论上，PHP（比如使用Slim）可以做同样的事。但我们非但得不到上述好处，还会搞得一团糟：在Apache/PHP上进行操作会更加复杂，基础设施也会变得有些奇怪。
选择框架
那个最终被我们用Node.js替换掉的PHP应用，主要有如下职责：
登录和授权
路由选择和服务端模板引擎（服务HTML）
引导前端应用
代理服务（为了回避CORS）
服务静态资源（js，css，images）
这些就是我们需要替换掉的基本功能。
我们尝试过不少框架，Express令人叹为观止（试一下我们评估过的spreadsheet）。任何未基于Express 的框架看起来都不靠谱。Express通俗易懂，并有良好的文档。另外，可以招聘到正经培训过Express的人。
我们添加了一些kraken的核心模块（express-enrouten用于路由选择、lusca负责安全）；此外，i18n-node提供国际化支持，模板引擎使用Swig（我们后来放弃了Swig。呵呵，开源软件还是有风险的）。
我们考虑过全盘使用kraken，但是从原来的服务端php模板引擎Twig切换到Swig直截了当，还很快捷。此外，kraken里面的Dust和i18n也不讨人喜欢。
编写服务器
选好了框架，下一步该写服务器了。
使用Apache+PHP时，你不需要再写一个服务器。Apache本身就是服务器，PHP是应用。如果使用Node.js，服务器和应用是同一个。从Apache/PHP转到PHP，你需要处理一些之前自然而然使用的功能，这一点很重要。使用Apache，你（或者系统管理员）配置服务器，在PHP应用里完全不用关心Apache为你处理的那些事。Node.js却以一种不同的方式来工作。
提供静态文件服务
毋庸置疑，提供静态文件服务是Apache的核心功能。Node.js与此不同，你要在应用中配置静态文件服务。幸运的是这很简单，有良好的文档说明，并且是在Express中实现的。
日志
很多基本的Apache配置为你提供访问日志和错误日志。使用Node.js时，估计你也猜到了，同样需要在应用中配置。所幸很多优秀的开源软件包使之变得很简单。Morgan是一个基本的请求日志记录器，它配置简单，允许你把日志写到输出流（标准输出设备或文件）。如果你需要把日志写到数据库，或者有别的（更高级的）日志需求，那就试一下winston吧。
代理
我们有一个基本需求：能够代理传输客户端ajax请求到后台服务。相比于处理CORS头，代理所有来自相同域的请求要简单得多。但你要想通过代理使用webpack-dev-server（正如我们所做的），就必须在Node.js应用中处理这一问题。http-proxy是一个简单可靠的解决方案。
剩下的工作
除了上面提到的，还有一些列别的工作需要完成。我们从一个MVC应用谈起，该应用基于 CodeIgniter(CI)框架，为一系列单页应用提供服务。大部分工作就是移植：
CI控制器移植到Express路由选择器和中间件（包括登录和认证）
Twig模板引擎移植到Swig（这一步比较琐碎）
Service层数据访问（以便正常启动客户端单页应用）
上面并未列出CodeIgniter模型这一关键组件。事实上根本不用重写PHP模型！太给力了！我们的客户端应用使用Backbone模型。当然这要扩展Backbone.Model.sync，从而使之全局地工作在服务器和客户端。
部署
如果你的app规模较大，不应该一次性全部上线。可以通过渐进式部署的方式逐步上线。我们因此花费了好几周。
渐进式部署的优点：
最小化bug范围
每次在发布一部分路由及功能的同时，其他工程师可以正常进行开发
对正在进行的功能开发和改进影响最小 — 新功能可以继续发布（这可能导致重复的工作）
如果操作得当，可以快速回滚到之前的服务
NGINX很不错
该如何逐步上线呢？我们在众多的服务器中挑选了Nginx。
1
2
3
4
5
+----------+
http | |--->
Apache/PHP
request---->| Nginx
|
| |--->
Node.js
+----------+
Nginx允许你一次只“打开”一个路由（如果发现情况不妙就关掉 — 正如我们多次遇到的），这给了你很大的自由度。我们也发现打开路由的时候不用部署代码，这很有帮助。这在一周一次的发布计划里，为我们提供了一些回旋空间。
不过有一个缺点，你需要确保客户端代码同时接受旧的Apache/PHP服务器和新的Node.js服务器提供的服务。这并不可怕，不过你要把旧服务器上未优化的功能移植到新的服务器。屏住呼吸去做吧（记得写一个便利贴去清理你的技术债）。
总结
从头到尾，整个移植工作大概花费了一年。这听起来可能有点荒谬，不过这个时间表包括决策过程（比较匆忙）、基于Express写一个满足需求的核心框架、移植所有功能、逐步渐进式上线。此外，请记住，我们始终只有一两个开发者为之工作 — 并且是兼职。
如果你想尝试一下，请慎重考虑。你的团队能否受益？你的整个组织能否受益？如果你来自商业组织，请记住商业需要持续运转。你需要在商业目标和工程目标之间找到良好的平衡。
为什么drupal8要选择twig作为逡drupal6就可以使用非PHP的模板引擎，drupal8也不是一定要用twig，也是可以用PHP做模板的。但这样就需要 前端开发人员掌握PHP才可以 。用twig有它的好处，例如前端入门门槛低，可以比较安全地把整个THEME的权限分配给其他模板团队进行开发等。
thinkphp项目中怎么加载twig引擎如果想用第三方的模板引擎，需配置的文件是项目配置文件；
可以去ThinkPHP/Lib/Behavior/ParseTemplateBehavior.class.php文件中查看
仔细查看默认的配置想，可以到自己的项目配置文件修改；
'TMPL_ENGINE_TYPE'=> 'Think', // 默认模板引擎 以下设置仅对使用Think模板引擎有效
'TMPL_L_DELIM' => '{',// 模板引擎普通标签开始标记
'TMPL_R_DELIM' => '}',// 模板引擎普通标签结束标记
.....
你可以根据自己的需要进行设置
关于php模版引擎twig的介绍到此就结束了，不知道本篇文章是否对您有帮助呢？如果你还想了解更多此类信息，记得收藏关注本站，我们会不定期更新哦。
查看更多关于php模版引擎twig php模版引擎原理的详细内容...