摘要：后端的动态模板后端通常会使用模板文件来动态返回前端页面。后端代码调用文件可以看作是函数调用。这里虽然处理的是后端模板文件和前端的一个结合，但其思想可以利用在别的地方。
后端的动态模板
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功能，便可以把模板文件本身当作接口，从而将实现与定义分离。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/98155.html
摘要：但似乎他们的职责在以前甚至于现在都并不明确，虽然前端是跟浏览器打交道，但是最终浏览器拿到的页面是服务器通过模板生成的一个临时静态页面而已。当然，一般传统上的开发协作模式有两种一种是前端先写一个静态页面，写好后，让后端去套模板。随着不同终端（Pad/Mobile/PC)的兴起，对开发人员的要求越来越高，纯浏览器端的响应式已经不能满足用户体验的高要求，往往需要针对不同的终端开发定制的版本，为了提...
摘要：怎么做前后端的分离我目前的做法是将作为一种服务存在，仅需要提供接口即可，前端目前采用，调用后端，解析数据，静态页面。采用，充当层，前后端实现了真正的分离，但还是有点问题的。 什么是前后端分离 对于这个问题，其实可以看看我的学习历程，我觉得很好的体现了Web开发模式的演化。 石器时代：那正是本人刚学JSP的时候，写了一个简单的商城DEMO，所有的业务逻辑，数据库的交互以及Javascri...
摘要：什么是前后分离前后端分离并不是什么新鲜事，到处都是前后端分离的实践。然而一些历史项目在从一体化设计转向前后端分离的架构时，不可避免的会遇到各种各样的问题。搞了一个前后分离，需要分离部署。 探究 ：深入聊聊前后分离架构 前后分离，一直是一个相当泛泛的问题，前后分离到底好不好？没有绝对的对，没有绝对的错，业界就这个问题已经激烈的探讨几年了.出现讨论的点在于：分离当然是好的,但是以什么样的服...
摘要：什么是前后分离前后端分离并不是什么新鲜事，到处都是前后端分离的实践。然而一些历史项目在从一体化设计转向前后端分离的架构时，不可避免的会遇到各种各样的问题。搞了一个前后分离，需要分离部署。 探究 ：深入聊聊前后分离架构 前后分离，一直是一个相当泛泛的问题，前后分离到底好不好？没有绝对的对，没有绝对的错，业界就这个问题已经激烈的探讨几年了.出现讨论的点在于：分离当然是好的,但是以什么样的服...
摘要：什么是前后分离前后端分离并不是什么新鲜事，到处都是前后端分离的实践。然而一些历史项目在从一体化设计转向前后端分离的架构时，不可避免的会遇到各种各样的问题。搞了一个前后分离，需要分离部署。 探究 ：深入聊聊前后分离架构 前后分离，一直是一个相当泛泛的问题，前后分离到底好不好？没有绝对的对，没有绝对的错，业界就这个问题已经激烈的探讨几年了.出现讨论的点在于：分离当然是好的,但是以什么样的服...
阅读 1591·2023-05-11 16:55
阅读 3375·2021-08-10 09:43
阅读 2442·2019-08-30 15:44
阅读 2325·2019-08-29 16:39
阅读 473·2019-08-29 13:46
阅读 1876·2019-08-29 13:29
阅读 803·2019-08-29 13:05
阅读 496·2019-08-26 13:51
