『壹』 sublime text 3 有 javascript 提示插件嗎
Sublime
CodeIntel 是一個代碼提示、補全插件,支持
JavaScript、Mason、XBL、XUL、RHTML、SCSS、Python、HTML、Ruby、Python3、XML、Sass、
XSLT、Django、HTML5、Perl、CSS、Twig、Less、Smarty、Node.js、Tcl、TemplateToolkit 和
php 等語言,是 Sublime Text 自帶代碼提示功能的很好擴展。它還有一個功能就是跳轉到變數、函數定義的地方,十分方便。
使用 SublimeCodeIntel 之前你需要安裝相應程序並把路徑寫入 ~/.codeintel/config 或 project_root/.codeintel/config 中,ReadMe 中有詳細的 說明。
git:https://github.com/SublimeCodeIntel/SublimeCodeIntel
Sublime
CodeIntel:https://sublime.wbond.net/packages/SublimeCodeIntel
『貳』 twig 模板變數 set 賦值時如何引用 js 函數的返回值
直接是得不到的
因為模板中的變數要先於JS執行。
這需要你對網頁從請求到展示的整個過程有所了解。
要知道,在一個頁面上,JS是運行在客戶端瀏覽器上的,而PHP是運行在伺服器上的,
而用戶在請求一個網頁的時候,伺服器會先運行PHP,完成之後遞交(傳遞)給用戶瀏覽器,然後瀏覽器載入這個頁面,如果其中有JS代碼,則執行它。
那麼,如果瀏覽器想要向伺服器遞交數據的話,可以使用get或者post傳值的方式,一種是表單方式,一種是ajax方式,都有get和post兩種,這個需要你更深入地學習一下才行,不是在這里一兩句就能講清楚的。
你的這個問題,也是需要用表單或者是ajax向伺服器遞交表單的,然後在伺服器上,對這個頁面進行第二次執行的時候(也就是伺服器獲取到用戶傳來的數據之後)才能對這個數據進行處理。
『叄』 如何在逯惺褂PHP 而不是 Twig
因為Symfony默認的模板引擎是twig,但如果你想要,你仍然可以使用純php代碼。這兩個模板引擎在symfony中都被支持。Symfony 在 PHP 上添加了一些不錯的特性,使得使用 PHP 來編寫模板更強大。
如果你選擇不使用Twig並禁用它,你需要通過kernel.exception事件,實現你自己的異常處理程序。如果還有不明白的話,你也可以去後盾人平台看看php基礎教學視頻看看,也是不錯的選擇,希望能幫到你,給個採納吧謝謝(੭‾᷄㉨‾᷅)੭
『肆』 用sublime text 3寫C++程序有什麼好用的插件或者技巧嗎
All Autocomplete
Sublime Text 默認的 Autocomplete 功能只考慮當前的文件,而 AllAutocomplete 插件會搜索所有打開的文件來尋找匹配的提示詞。
Themr
sublime可以下載很多風格樣式,用這個插件可以管理所有的風格
這些就是我們大部分要用到的,其它的我就不細說了,因為每個人不一樣,比如說git,sass,svn這些你們可以自己查找
插件的網址如下,你可以找到你喜歡的插件
https://packagecontrol.io/browse
最近出現sublime:3103版本好多沒有激活碼
今天在這補充下文章
『伍』 為什麼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' => '}',// 模板引擎普通標簽結束標記
.....
你可以根據自己的需要進行設置
『柒』 sublime text 3 有什麼插件
Sublime Text作為一個盡為人知的代碼編輯器,其優點不用贅述。界面整潔美觀、文本功能強大,且運行速度極快,非常適合編寫代碼,寫文章做筆記。Sublime Text還支持Mac、Windows和Linux各大平台,方便用戶使用。種類繁多、功能強大的插件更給Sublime Text 3錦上添花。下載Package Control後就可以迅速的開啟插件之路。
1. Soda Theme
Sublime Text 3中較為常用的一款自定義編輯器主題,用過的人都說好。Soda Theme包含代碼著色、標簽、圖標,擁有light和dark兩種顏色主題便於用戶在不同時間段使用。
Github:https://github.com/buymeasoda/soda-theme/
2. Sublime APICloud Plugins
Sublime APICloud Plugins是APICloud為開發者提供的一套開源的Sublime Text擴展插件,包括:應用管理、應用框架、頁面模板、代碼提示、代碼管理、Widget打包、真機同步、日誌輸出、管理自定義AppLoader等功能,其他的功能插件也在不斷增加,這些插件已被Package Control成功收錄,開發者可以直接在Sublime Text3中下載安裝;所有插件都已開源,開發者也可以在此基礎上按需求擴展自己的插件。
插件下載:http://www.apicloud.com/devtools
3. ColorPicker
編輯CSS樣式的時候, ColorPicker調色盤不僅可以查看顏色值,更可以輕松調好顏色。ColorPicker同時還是一個雙向選擇顏色的功能,既可以在調色板中選好顏色將其使用至文檔中,也可以迅速定位文檔中的某一種顏色值到調色板中。
插件下載:https://github.com/weslly/ColorPicker
4. Emmet
Emmet (前身是 Zen Coding)是一個前端開發不可缺少的插件,它讓編寫 HTML和CSS代碼變得簡單,節省大量時間。Emmet可使開發者用縮寫形式書寫代碼,再用「擴展」功能自動將代碼擴展至完整樣式。
早在2009年,Zen Coding作為具有革命性的HTML和CSS代碼編輯插件一經問世,直到現在幫助了無數的開發者,減少他們的時間,使得編寫代碼變得簡便有趣。現在,Emmet已經超越了Zen Coding到達了更高層次,普適性的功能將給更多的開發者帶來便利。
插件下載:https://github.com/sergeche/emmet-sublime
5. SublimeCodeIntel
SublimeCodeIntel 作為一個代碼提示和補全插件,支持 JavaScript、Mason、XBL、XUL、RHTML、SCSS、Python、HTML、Ruby、Python3、XML、Sass、XSLT、Django、HTML5、Perl、CSS、Twig、Less、Smarty、Node.js、Tcl、TemplateToolkit 和 PHP 等所有語言,是 Sublime Text 自帶代碼提示功能基礎上一個更好的擴展,自帶代碼提示功能只可提示系統代碼,而SublimeCodeIntel則可以提示用戶自定義代碼。SublimeCodeIntel支持跳轉到變數、函數定義的功能,另外還有自動補全的功能,十分方便。
插件下載:https://github.com/SublimeCodeIntel/SublimeCodeIntel
6. FileDiffs
FileDiffs插件可以讓開發者比較兩個不同文件的差異,比較的對象包括當前文件、另一文件、剪切板中的代碼甚至未保存文件等。
插件下載:https://github.com/colinta/SublimeFileDiffs
7. SublimeLinter
SublimeLinter是少數幾個能在sublime text 3工作的代碼檢查插件,SublimeLinter支持JavaScript、CSS、HTML、Java、PHP、Python、Ruby等十多種開發語言,但前提是需要配置相應語言的環境,要檢查JavaScript代碼需要安裝node.js,檢查PHP代碼需要安裝PHP並配置環境等。SublimeLinter可以及時提示編寫代碼中存在的不規范和錯誤的寫法,並培養我們良好的編碼習慣和風格。
插件下載:https://github.com/SublimeLinter/SublimeLinter/tree/sublime-text-3
8. Alignment
Aligment插件讓開發者自動對齊代碼,包括PHP、CSS、JavaScript語言。使得代碼看起來更整齊美觀,更具可讀性。
插件下載:https://github.com/wbond/sublime_alignment
Sublime Text 3中的插件種類繁復,功能強大,以上是開發者最常用的8大插件,希望給各位開發者節省插件選擇的時間,提供編寫代碼的效率。
『捌』 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寫一個滿足需求的核心框架、移植所有功能、逐步漸進式上線。此外,請記住,我們始終只有一兩個開發者為之工作 — 並且是兼職。
如果你想嘗試一下,請慎重考慮。你的團隊能否受益?你的整個組織能否受益?如果你來自商業組織,請記住商業需要持續運轉。你需要在商業目標和工程目標之間找到良好的平衡。
『玖』 php symfony twig怎麼寫源生php
去控制器寫 還要花時間找 twig又不支持
『拾』 PHP twig 文件修改後如何刷新緩存或者之類的操作能看到網頁修改後的效果
twig 沒有什麼緩存
我猜你的意思是 你剛剛改了個twig模板里的東西 發現刷新了好幾次 還是之前的效果,然後過了一會刷新,發現效果出來了,我猜估計是這樣
我猜 你php的 `opcache` 打開的,你關掉就行了!