php模板引擎twig,php模板引擎 性能比較

本文目錄一覽：

• 1、thinkphp項目中怎麼載入twig引擎
• 2、PHP twig 文件修改後如何刷新緩存或者之類的操作能看到網頁修改後的效果
• 3、golang 使用twig模板引擎，站在php的肩膀上！
• 4、PHP 模板引擎的簡單代碼怎麼弄！
• 5、為什麼drupal8要選擇twig作為逡
• 6、Node.js代碼轉php

thinkphp項目中怎麼載入twig引擎

如果想用第三方的模板引擎，需配置的文件是項目配置文件；

可以去ThinkPHP/Lib/Behavior/ParseTemplateBehavior.class.php文件中查看

仔細查看默認的配置想，可以到自己的項目配置文件修改；

‘TMPL_ENGINE_TYPE’= ‘Think’, // 默認模板引擎 以下設置僅對使用Think模板引擎有效

‘TMPL_L_DELIM’ = ‘{‘,// 模板引擎普通標籤開始標記

‘TMPL_R_DELIM’ = ‘}’,// 模板引擎普通標籤結束標記

…..

你可以根據自己的需要進行設置

PHP twig 文件修改後如何刷新緩存或者之類的操作能看到網頁修改後的效果

twig 沒有什麼緩存

我猜你的意思是 你剛剛改了個twig模板里的東西 發現刷新了好幾次 還是之前的效果，然後過了一會刷新，發現效果出來了，我猜估計是這樣

我猜 你php的 `opcache` 打開的，你關掉就行了！

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一下吧！

PHP 模板引擎的簡單代碼怎麼弄！

//phpcms 的核心模板解析函數

/*

*/

function template_parse($str)

{

$str = preg_replace(“/\{(\\$[a-zA-Z0-9_\[\]\’\”\$\x7f-\xff]+)\}/es”, “addquote(‘?php echo \\1;?’)”,$str);

$str = preg_replace(“/\{([A-Z_\x7f-\xff][A-Z0-9_\x7f-\xff]*)\}/s”, “?php echo \\1;?”,$str);

$str = preg_replace(“/([\n\r]+)\t+/s”,”\\1″,$str);

$str = preg_replace(“/\\!\-\-\{(.+?)\}\-\-\/s”, “{\\1}”,$str);

$str = preg_replace(“/\{template\s+(.+)\}/”,”\n?php include template(\\1); ?\n”,$str);

$str = preg_replace(“/\{include\s+(.+)\}/”,”\n?php include \\1; ?\n”,$str);

$str = preg_replace(“/\{php\s+(.+)\}/”,”\n?php \\1?\n”,$str);

$str = preg_replace(“/\{if\s+(.+?)\}/”,”?php if(\\1) { ?”,$str);

$str = preg_replace(“/\{else\}/”,”?php } else { ?”,$str);

$str = preg_replace(“/\{elseif\s+(.+?)\}/”,”?php } elseif (\\1) { ?”,$str);

$str = preg_replace(“/\{\/if\}/”,”?php } ?”,$str);

$str = preg_replace(“/\{loop\s+(\S+)\s+(\S+)\}/”,”?php if(is_array(\\1)) foreach(\\1 AS \\2) { ?”,$str);

$str = preg_replace(“/\{loop\s+(\S+)\s+(\S+)\s+(\S+)\}/”,”\n?php if(is_array(\\1)) foreach(\\1 AS \\2 = \\3) { ?”,$str);

$str = preg_replace(“/\{\/loop\}/”,”\n?php } ?\n”,$str);

$str = preg_replace(“/\{tag_([^}]+)\}/e”, “get_tag(‘\\1’)”, $str);

$str = preg_replace(“/\{\\$([a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*\(([^{}]*)\))\}/”,”?php echo \\1;?”,$str);

$str = preg_replace(“/\{(\\$[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*)\}/”,”?php echo \\1;?”,$str);

}

function addquote($var)

{

return str_replace(“\\\””, “\””, preg_replace(“/\[([a-zA-Z0-9_\-\.\x7f-\xff]+)\]/s”, “[‘\\1’]”, $var));

}

為什麼drupal8要選擇twig作為逡

drupal6就可以使用非PHP的模板引擎，drupal8也不是一定要用twig，也是可以用PHP做模板的。但這樣就需要 前端開發人員掌握PHP才可以 。用twig有它的好處，例如前端入門門檻低，可以比較安全地把整個THEME的許可權分配給其他模板團隊進行開發等。

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寫一個滿足需求的核心框架、移植所有功能、逐步漸進式上線。此外，請記住，我們始終只有一兩個開發者為之工作 — 並且是兼職。

如果你想嘗試一下，請慎重考慮。你的團隊能否受益？你的整個組織能否受益？如果你來自商業組織，請記住商業需要持續運轉。你需要在商業目標和工程目標之間找到良好的平衡。