掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
最近微構(gòu)網(wǎng)絡(luò)接手了一個(gè)從其他團(tuán)隊(duì)轉(zhuǎn)移過來的一個(gè)項(xiàng)目,因?yàn)榭蛻糁暗姆?wù)團(tuán)隊(duì)解散了。在交接過程中客戶描述了一些問題,其中一個(gè)基礎(chǔ)問題就是說這個(gè)系統(tǒng)只能在windows系統(tǒng)里面運(yùn)行,而在centos等linux系統(tǒng)中運(yùn)行不了,直接出現(xiàn)報(bào)錯(cuò)頁(yè)面。
因?yàn)樵诖酥拔覀円呀?jīng)了解到該項(xiàng)目后端采用php+MySQL開發(fā),而且功能也沒有特別特殊的東西,理論上不存在這種兼容性問題。打開調(diào)試模式發(fā)現(xiàn)這樣的頁(yè)面:
這個(gè)報(bào)錯(cuò)太正常不過了,就是提示模板文件不存在嘛,像這個(gè)項(xiàng)目就是典型的模板引擎實(shí)現(xiàn)邏輯上的前后端分離,但是并不是真正意義上的前后端分離。這種報(bào)錯(cuò)在開發(fā)過程中太常見了。然而為什么在windows系統(tǒng)上就沒問題,而放到linux系統(tǒng)中就有問題呢?
稍微了解windows和linux系統(tǒng)的人都知道windows對(duì)大小寫不敏感,而linux系統(tǒng)對(duì)大小寫敏感。原因就在這個(gè)地方,因?yàn)樯鲜鰧?shí)際報(bào)錯(cuò)的模板文件名為testSql.html,文件名為駝峰命名法,其中是大寫的S。然而在調(diào)用的時(shí)候根據(jù)模板解析規(guī)則解析成了testsql,成為完全小寫的的了。
如何解決?
最笨的方式就是在對(duì)應(yīng)的控制器中把模板調(diào)用改成統(tǒng)一的名稱,這樣肯定是不會(huì)再出錯(cuò)了。如果一個(gè)項(xiàng)目頁(yè)面數(shù)量很少,這種最笨的方式也是非常有效的一種方式,但是如果頁(yè)面數(shù)量多,那必然就希望用更快的方式來處理這個(gè)坑了。其實(shí)只要理解thinkphp的模板加載機(jī)制就能批量的解決上述問題,下面不解析具體分析過程,只給一個(gè)分析出來的結(jié)果。
可以知道進(jìn)行模板加載的核心代碼位于thinkphp\library\think\view\driver\Think.php中,而上述報(bào)錯(cuò)的頁(yè)面提示的就是這個(gè)thinkphp自帶類中的fetch方法。
而真正進(jìn)行處理的則是該方法所引用的parseTemplate方法,官方給的注釋是“自動(dòng)定位模板文件”,我們可以修改該方法進(jìn)行批量處理(一般情況下,不建議修改開發(fā)框架的核心源代碼;因?yàn)闀?huì)給后續(xù)框架升級(jí)帶來麻煩,而且某些框架的許可協(xié)議可能不允許這么干,這里僅供思路參考)。
下面我們截取其中一小段為例來講解下,以在控制器中直接使用$this->fetch()方法加載模板為例,也就是fetch方法不傳參數(shù),而讓框架的模板加載機(jī)制自動(dòng)引用模板。對(duì)應(yīng)的核心代碼就是:
$template = str_replace(‘.’, DS, $controller) . $depr . (1 == $this->config['auto_rule'] ? Loader::parseName($request->action(true)) : $request->action());
而跟最后模板文件名相關(guān)的其實(shí)就是:
1 == $this->config['auto_rule'] ? Loader::parseName($request->action(true)) : $request->action()
其中$this->config['auto_rule'] 是模板配置的一個(gè)參數(shù),它有兩個(gè)值(?1 解析為小寫+下劃線 2 全部轉(zhuǎn)換小寫,默認(rèn)是1),而$request->action()這個(gè)就是控制器的方法名,默認(rèn)是會(huì)直接全部轉(zhuǎn)化為小寫,如果傳參true會(huì)保留原始狀態(tài)。而?Loader::parseName則是把駝峰命名的大寫字母轉(zhuǎn)成小寫且在它前面加下劃線。
所以依據(jù)上述思路,對(duì)有問題的部分,進(jìn)行有標(biāo)記的進(jìn)行處理即可。比如已有的控制器對(duì)應(yīng)的模板文件名都是駝峰文件名,那么我們可以根據(jù)符合條件控制器,修改代碼:Loader::parseName($request->action(true)) 改成$request->action(true)即可,也就是不自動(dòng)變成下劃線形式。具體需要修改什么得按照之前留下的坑而來的。
建議
我們寫代碼的時(shí)候一定要考慮跨平臺(tái)的兼容性和后續(xù)擴(kuò)展迭代的便利性,不要圖一時(shí)快活,隨心所欲。到頭來留下巨多的坑等待自己或者后續(xù)接手的其他開發(fā)人員,其實(shí)在整個(gè)行業(yè)內(nèi)不少的加班都是因?yàn)檫@樣的不嚴(yán)謹(jǐn)造成的,很多甚至出現(xiàn)死循環(huán),直到拖死整個(gè)項(xiàng)目。
所以建議大家有開發(fā)需求的時(shí)候,請(qǐng)謹(jǐn)慎選擇開發(fā)團(tuán)隊(duì),因?yàn)椴⒉皇琴M(fèi)用越低、速度越快的就越好,前期低的成本很可能在后續(xù)過程中付出幾倍甚至數(shù)十倍的代價(jià)。很多時(shí)候我們團(tuán)隊(duì)是不愿意接手第三方團(tuán)隊(duì)開發(fā)的后的產(chǎn)品,因?yàn)檫@樣的產(chǎn)品對(duì)我們和客戶來講都是性價(jià)比很低的。客戶覺得我的東西都做好了只是存在很多使用上的問題,修改起來應(yīng)該很簡(jiǎn)單;而實(shí)際上往往接手這樣的項(xiàng)目來修改比重新開發(fā)一個(gè)同樣復(fù)雜度的產(chǎn)品花費(fèi)的時(shí)間和人力成本會(huì)更多。
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流