重構后端模板文件的一種實踐

JeOam 發布于2019-08-23 12:14 / 1327人閱讀

摘要：后端的動態模板后端通常會使用模板文件來動態返回前端頁面。后端代碼調用文件可以看作是函數調用。這里雖然處理的是后端模板文件和前端的一個結合，但其思想可以利用在別的地方。

后端的動態模板

Java后端通常會使用ftl（freemarker template language）模板文件來動態返回前端頁面。這個工作，通常還可以用jsp、php文件來實現。但這些動態模板的實現，通常是在已有的html文件上對特定的需要做動態處理的部分做改寫。這對小項目來講沒什么不對。可如果你的頁面數量足夠多，維護它們將成為一件異常困難的事情。

Nodejs大前端技術

在目前的大前端技術棧下，Nodejs的各種框架讓前端開發變得規矩不少。我的一個理解是，傳統前端的html+css+js的技術棧的最大問題在于其模塊化、組織能力像是一個教學語言，應有的語句控制和代碼復用的技術，都顯得蒼白無力。

就html的編寫來講，幾乎不存在一種類似函數的復用方式，能夠簡化重復的UI component的生成。你只能不斷地去寫一些重復的、雜亂的代碼。整體上來講，這不僅難以做后期的維護，也無法輕易地看懂其間的代碼邏輯。

一句話來講，這些代碼非常類似于機器代碼或者匯編代碼。沒有高級語言的精準控制和抽象層去對代碼做宏觀把控。

Pugjs是一個很好的html預處理項目。它的基本想法是：

不要去直接編寫“底層”的html代碼，而是用自己定義的一套語法去編寫pug文件。

通過這個pug文件去生成出html代碼。特別的，在它的語法中，你不必再寫一大堆的尖括號和與前后呼應的tag。如同Python，僅僅依靠代碼的對齊方式，就可以自動識別相應的作用域范圍。例如

 
    
         First tip 
         Second tip 
         Third tip

這樣語義簡單、語法繁瑣的一堆代碼，在pug下可以簡化為

div
    ul
        li First tip
        li Second tip
        li Third tip

但這還不是最誘人的技術，因為這無非是加入了一些語法糖。最為誘人的是pug提供的函數，它能夠定義一個函數去生成某個組件。

例如，如果你需要定義一組table，每個table僅僅是表頭或者其中一部分的數據不一樣，你該如何處理？傳統的方式當然是復制粘貼一堆模板代碼，然后一個個地去修改里面的數據。

而pug的處理方式就要好太多，完全符合將數據和代碼分離的思想。定義函數：

mixin leftbox-gen(dataObj)
        table.table
            thead
                tr
                    th(scope="col") #{dataObj.title}
            tbody
                each area in dataObj.areas
                    tr
                        td
                            .box-title #{area.name}
                            ul
                                each subarea in area.subareas
                                    li
                                        a(id=subarea.id, href=subarea.url) #{subarea.name}

這樣就可以根據通過定義json格式的dataObj去引用函數：

+leftbox-gen(cs_leftbox_data)

你通過不同的json數據，就能夠生成不同的table出來。這就實現了代碼的模塊化和以及數據和業務代碼的分離。要做出新的table component，你只需要改變數據就可以了。

這樣的實現方式在別的高級語言中是很常見的，但是在傳統的前端代碼中，這常常難以見到。原因就在于，html代碼更像是沒有抽象層的機器代碼，只是一大堆的實際操作，而缺少抽象層的高效管理。

前端預處理和后端動態模板的結合

像pug這樣優秀的工具，如果能夠用來管理后端的ftl模板當然會相當合適。優秀的語法糖、代碼模塊化、數據和業務邏輯的分離，實在是相當誘人的選擇。

但這樣的理念真要實施在生產代碼中，特別是用來重構已有的legacy code時，就不大容易了。

例如，pug只能生成html代碼，且生成出來的位置通常是在一個統一的地方。可ftl代碼卻分散在各個不同Java工程的不同目錄之下。這兩者很難統一到一起。

或許一個直接的想法是，不如直接把所有的ftl都放到一個地方，這樣就不用把模板語言分散到各個不同項目的不同文件夾里，而難以維護。

但這種方案帶來的一個麻煩是，如果真的把后端的ftl文件挪動了位置，那么你后端代碼的接口部分就不得不做修改。而這樣的接口部分其數量并不少。既要做出大量的修改，還要保證它們的正確性，并不是一件輕松的事情。

經過大量的思考和嘗試，我得出的一個解決方案是：

使用Pugjs生成出統一的ftl文件，放在同一個公共資源文件夾下。讓每一個具體項目下的ftl文件中，直接include這個公共資源文件夾中ftl內容。

這種做法的一個精妙之處是：它將ftl文件當作函數接口來使用。后端Java代碼調用ftl文件可以看作是函數調用。而函數實現并不需要直接放在這個ftl文件里，而是可以放在別的地方做引用。這就把實現和調用部分，通過一個多帶帶的文件分離開了。

這里雖然處理的是后端模板文件和前端的一個結合，但其思想可以利用在別的地方。如果一個模板文件具備了include功能，便可以把模板文件本身當作接口，從而將實現與定義分離。

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/98155.html

關于前后端分離與模板引擎

摘要：但似乎他們的職責在以前甚至于現在都并不明確，雖然前端是跟瀏覽器打交道，但是最終瀏覽器拿到的頁面是服務器通過模板生成的一個臨時靜態頁面而已。當然，一般傳統上的開發協作模式有兩種一種是前端先寫一個靜態頁面，寫好后，讓后端去套模板。隨著不同終端（Pad/Mobile/PC)的興起，對開發人員的要求越來越高，純瀏覽器端的響應式已經不能滿足用戶體驗的高要求，往往需要針對不同的終端開發定制的版本，為了提...

cnTomato 2019-04-23 13:40 評論0 收藏0
前后端分離的一點實踐

摘要：怎么做前后端的分離我目前的做法是將作為一種服務存在，僅需要提供接口即可，前端目前采用，調用后端，解析數據，靜態頁面。采用，充當層，前后端實現了真正的分離，但還是有點問題的。什么是前后端分離對于這個問題，其實可以看看我的學習歷程，我覺得很好的體現了Web開發模式的演化。石器時代：那正是本人剛學JSP的時候，寫了一個簡單的商城DEMO，所有的業務邏輯，數據庫的交互以及Javascri...

enda 2019-08-14 12:53 評論0 收藏0
《從零構建前后分離web項目》探究 - 深入聊聊前后分離架構

摘要：什么是前后分離前后端分離并不是什么新鮮事，到處都是前后端分離的實踐。然而一些歷史項目在從一體化設計轉向前后端分離的架構時，不可避免的會遇到各種各樣的問題。搞了一個前后分離，需要分離部署。探究：深入聊聊前后分離架構前后分離，一直是一個相當泛泛的問題，前后分離到底好不好？沒有絕對的對，沒有絕對的錯，業界就這個問題已經激烈的探討幾年了.出現討論的點在于：分離當然是好的,但是以什么樣的服...

whinc 2019-08-23 11:44 評論0 收藏0
《從零構建前后分離web項目》探究 - 深入聊聊前后分離架構

摘要：什么是前后分離前后端分離并不是什么新鮮事，到處都是前后端分離的實踐。然而一些歷史項目在從一體化設計轉向前后端分離的架構時，不可避免的會遇到各種各樣的問題。搞了一個前后分離，需要分離部署。探究：深入聊聊前后分離架構前后分離，一直是一個相當泛泛的問題，前后分離到底好不好？沒有絕對的對，沒有絕對的錯，業界就這個問題已經激烈的探討幾年了.出現討論的點在于：分離當然是好的,但是以什么樣的服...

Corwien 2019-08-23 11:40 評論0 收藏0
《從零構建前后分離web項目》探究 - 深入聊聊前后分離架構

摘要：什么是前后分離前后端分離并不是什么新鮮事，到處都是前后端分離的實踐。然而一些歷史項目在從一體化設計轉向前后端分離的架構時，不可避免的會遇到各種各樣的問題。搞了一個前后分離，需要分離部署。探究：深入聊聊前后分離架構前后分離，一直是一個相當泛泛的問題，前后分離到底好不好？沒有絕對的對，沒有絕對的錯，業界就這個問題已經激烈的探討幾年了.出現討論的點在于：分離當然是好的,但是以什么樣的服...

lunaticf 2019-08-19 11:06 評論0 收藏0