摘要:默認使用的是,因此從前端來說,和是可以整合的,而且并且試驗過,和整合也是前后端開發(fā)一個不錯的方案。前后端分離一直都是個梗,還是以團隊利益最大化考慮。當前端調整模板的時候,完全可以按照后端的變量分配方式進行處理。配合可謂是一個非常高效的方式。
FastD 默認使用的是 twig,因此從前端來說,twigjs 和 fastd是可以整合的,而且并且試驗過,twigjs和 fastd 整合也是前后端開發(fā)一個不錯的方案。
gulp安裝 gulp: npm install gulp --save
guip-twig安裝 gulp-twig: npm install gulp-twig --save
文檔地址: gulp-twig
其他: less, compass(由前端決定)可選安裝: npm install [options] --save
環(huán)境配置FastD: 2.0.x-dev
新建 gulpfile.js,編寫內容:
"use strict"; var gulp = require("gulp"), bundles = require("./bundles.json"), twig = require("gulp-twig"), tasks = (function (bundles) { var tasks = []; for (var i in bundles) { tasks.push(bundles[i].name); } return tasks; })(bundles) ; var resources = "./resources"; // todo. waiting... /** * Task list. * */ gulp.task("default", tasks, function () { console.log("Tasks: " + tasks.join(",")); console.log("Register bundles length: " + bundles.length); });
引入gulp,基礎的處理,如果沒有接觸過 npm(Node Package Manager) 和 gulp 的同學,可能要去學習下咯: npm gulp
這里的 require 當中有一個 bundles.json 配置文件,是因為 FastD 和 Symfony 一樣,模塊需要注冊,因此在開發(fā)環(huán)境中也需要配置相對應的配置文件,現(xiàn)在新建文件: bundles.json。文件中的所有模塊按照 app/application 的 registerBundles 里面注冊的模塊。
bundles.json:
[ { "name": "welcome", "path": "./src/Index/Resources", "data": { "title": "test title" } } ]
每個 bundle 均已一個對象存在,json 你懂的。其中 name 表示模塊名,path 表示模塊資源所在地址,data 是根據 twig 模板中所需的 "變量",也就是 {{ 變量名 }} 中所需要的變量。
再看看 gulpfile 文件,因為 FastD 中模板引擎實現(xiàn)兩個預定義函數(shù),所以在配置環(huán)境的時候也需要統(tǒng)一處理,函數(shù)分別為: url(name, args, format), asset(name, version),分別表示生成 url 地址,生成資源鏈接地址(link, script等資源地址)。
所以 gulpfile 也需要定義此函數(shù),實現(xiàn)的內容根據自己喜好調整:
var functions = [ { "name": "asset", func: function (args) { return args; // todo } }, { "name": "url", func: function (args) { return args; // todo } } ];
回頭看看上面的配置,因為 bundles 是以一個數(shù)組的形式組成,所以我們的配置需要根據動態(tài)注冊的 bundle 進行處理,不應該手動一個一個去操作,因為開發(fā)效率問題以及一些靈活性的問題。
循環(huán)每個 bundle 進行動態(tài)讀取配置:
/** * Register bundles. * */ bundles.forEach(function (bundle) { module.exports = function (gulp, twig, bundle) { var view = bundle.path + "/views"; var asset = bundle.path + "/assets"; var watch = bundle.name + ".watch"; gulp.task(watch , function() { console.log(bundle.name.replace(/(w)/,function(v){return v.toUpperCase()}) + "Bundle: task running......"); var tpl = gulp.src(view + "/**/*.twig") .pipe(twig({ base: view, data: bundle.data, functions: functions })) // output html .pipe(gulp.dest(resources + "/" + bundle.name + "/views")) ; var js = gulp.src(asset + "/**/*.js") .pipe(gulp.dest(resources + "/" + bundle.name + "/js")) ; var css = gulp.src(asset + "/**/*.css") .pipe(gulp.dest(resources + "/" + bundle.name + "/css")) ; }); gulp.task(bundle.name, [watch], function () { gulp.watch(view + "/**/*.twig", [watch]); gulp.watch(asset + "/**/*.css", [watch]); gulp.watch(asset + "/**/*.js", [watch]); }); }(gulp, twig, bundle); });
以上是完整配置,包括監(jiān)聽文件,此處監(jiān)聽文件變化動態(tài)生成文件。
生成規(guī)則,存放在 ./resources 下,按照模塊名分開, js, css, views 目錄分開,如果存在圖片,也是按照 images 區(qū)分,自行配制即可,如此類推。
配置已經完成,新增:
bundles.json
gulpfile.js
正是編碼之前哆嗦幾句,我們總說前后端分離,前后端分離,前后端分離,我也不知道前后端應該怎么分離,前后端為什么要分離。實際上很多人都想分離分離分離,但是想想,分離之后真的有你想象的那么好嗎?我看其不然,技術本身是相輔相成的東西,其實分離了之后,雖然說負責的東西和處理的東西單一了,但是在很多時候,這并不利于一個團隊以及一個項目的發(fā)展,因為這從一定基礎上隔閡了大家。
我更推薦是精通一種并且懂得與其他的技術交互,這并不是分離,而是更好地將自己熟悉的東西融合到其他技術當中,并且更好地與其他技術一起工作。
前后端分離一直都是個梗,還是以團隊利益最大化考慮。
前端通過以上配置,前端現(xiàn)在只需要關注自己的代碼,結構與后端一致即可,有變動需要同步到 git 并且與后端溝通
前端編寫的 twig 代碼存放在 {Bundle}/Resources/views & {Bundle}/Resources/assets,輸出通過 gulpfile 控制,環(huán)境,數(shù)據由自己控制,擺脫后端的依賴。
當前端調整模板的時候,完全可以按照后端的變量分配方式進行處理。并且后端可以很好地兼容和操作 twig 模板。后端也可以很好地處理 twig 模板。配合 git 可謂是一個非常高效的方式。
后端通過以上配置,后端現(xiàn)在只需要關注自己的代碼,結構與前端一致即可,有變動需要同步到 git 并且與前端溝通
后端現(xiàn)在就可以完全不用理會前端干啥了,完全可以做自己做的工作了,當前端有變動的時候,你可以第一時間看到變化的情況,而且發(fā)現(xiàn)有操作不當或者需要調整的地方,可以直接調整修改,前端進行代碼同步。
邏輯處理,動態(tài)變量分配都可以自由控制。
總結其實為啥這樣做?原理很簡單,雙方的工作應該自己都要清楚,但是雙方之間的工作對接也更應該統(tǒng)一并且易于處理,也就是說,中間的那一層應該是大家都能操作,并且雙方都作為監(jiān)督者,一方面可以提高效率,另一方面可以提高項目、團隊之間的溝通,還可以提高默契。
所以我覺得這是一個值得嘗試的方案。
如果你的工作中有使用用 twig 作為模板引擎,可以根據自己的業(yè)務定制自己對應的開發(fā)環(huán)境,提高效率是咱們要去認真對待的事情。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://systransis.cn/yun/21331.html
摘要:自發(fā)布以來,終于確定了發(fā)展的路線,最終還是和走在了一起,并且基于提供強大的性能支持。不同于,僅提供最基礎的核心主干,其他均由開發(fā)者自助組裝框架不會過度整合太多不必要的組件,現(xiàn)在不會,未來也不會。 自 3.0 發(fā)布以來,F(xiàn)astD 終于確定了發(fā)展的路線,最終還是和 Swoole 走在了一起,并且基于 Swoole 提供強大的性能支持。項目地址: FastD 優(yōu)勢: 簡單,靈活,開發(fā)服務...
摘要:繼版本之后,經過半年斷斷續(xù)續(xù)的迭代,現(xiàn)在版本終于迎來第一個穩(wěn)定版,未來會繼續(xù)對其進行研發(fā),除了本身的功能特性外,還會對其能夠提供的體系,生態(tài)進行完善。新特性新增進程管理命令,新增配置文件。也希望業(yè)界各個兄弟能夠指出產品的不足以及建議 繼3.1版本之后,經過半年斷斷續(xù)續(xù)的迭代,現(xiàn)在3.2版本終于迎來第一個穩(wěn)定版,未來會繼續(xù)對其進行研發(fā),除了本身的功能特性外,還會對其能夠提供的體系,生態(tài)進...
摘要:我們需要將業(yè)務或服務放置在網關背后,由網關統(tǒng)一處理請求入口,本身由多個入口的處理變成了一個入口,由網關進行統(tǒng)一調度。網關負責來搞這些事情,你只需要知道網關就好了。 構建完成 API 服務,配置中心之后,架構圖大致如下: showImg(https://segmentfault.com/img/remote/1460000010676395); 我們?yōu)楹涡枰W關 引用 別人 的一句話: ...
摘要:點擊前往中文地址先決條件簡單安裝下載地址下載或者其他都可以。版本處理方案新建格式日志文件。配置日志會隨著配置進行生成,結果如下忽略上述日志內容,程序看得懂即可配置推送到需要根據業(yè)務場景進行配置,現(xiàn)在顯示最簡單的配置。 過去咱們開發(fā)中,對日志這個環(huán)節(jié)其實并不太重視,直到有一天,應用出現(xiàn)異常,這個時候才想起來日志,但很可惜,為時已晚。 咱們做運維和開發(fā),除了救火,還需要防火,因此一些防范的...
摘要:調整配置文件在選項中,追加即可。有了以上系統(tǒng)常規(guī)監(jiān)控日志集中分析應用調用鏈監(jiān)控,我們的業(yè)務就可以變得更加透明,清晰,可控。相關文章最佳實踐四構建系統(tǒng)可視化監(jiān)控最佳實踐五構建日志分析 zipkin是一個開放源代碼分布式的跟蹤系統(tǒng),由Twitter公司開源,它致力于收集服務的定時數(shù)據,以解決微服務架構中的延遲問題,包括數(shù)據的收集、存儲、查找和展現(xiàn)。它的理論模型來自于Google Dappe...
閱讀 3524·2021-11-25 09:43
閱讀 1281·2021-09-08 09:45
閱讀 2654·2021-09-07 09:59
閱讀 1516·2021-08-09 13:45
閱讀 3370·2019-08-30 15:54
閱讀 706·2019-08-29 18:35
閱讀 523·2019-08-29 17:18
閱讀 1008·2019-08-29 14:10