我認爲大多數模板引擎很難用於設計師和前端開發人員，讓程序員負擔維護他們。您認爲模板是將業務邏輯與表示邏輯分開的最佳方式嗎？
設計師更新html模型後經常更新模板是一場噩夢，因爲您的模板不再與原始htmls兼容。
I had this problem for very long time，最近我有一個idea，但我不知道我是不是在重新發明一些東西，或者如果有更好的東西存在。
所以，我問你是否爲這個問題找到了更好的解決方案，如果是的話，哪一個呢？
我個人喜歡一些CMS解決方案使我能夠將我的模板分解爲很小的部分。 SiteCore通過佔位符和渲染映射到用戶控件來做到這一點。
我也在過去大量使用UserControls來突破常見的功能，如登錄，菜單，頁腳鏈接等，以便於將來修改或替換功能。 （ASP.NET）
您使用的是什麼模板引擎？像Smarty for PHP的東西？
自從我切換到從表現內容的完全分離，我從來沒有回頭一看，這裏的原因：
你的業務邏輯變得非常清楚。如果沒有混合使用HTML標籤和表示邏輯，代碼將佔用1/2的空間，並且少於1/2的時間來維護。通過在兩者之間指定一個形式化的接口（甚至作爲文本文件或維基筆記），可以緩解維護代碼和表示之間的鏈接的負擔，列出表示層呈現/需要的所有變量和值。
經常從設計人員的更改更新模板意味着您的表示層應細分爲各種「塊」，如菜單塊，頁面佈局塊和內容塊。在大多數頁面上，只有內容塊是不同的。當使用CSS和其他現代網絡技術進行正確的劃分和實施時，合理的設計更改將對您的演示代碼產生最小的影響。
CMSes將此過程自動化得更加完善，現在即使5-10個頁面網站都可以從使用CMS與手動編碼的HTML中獲益，從一致性和易用性支持角度來看。
代碼安全性 - Smarty不是PHP，因此您的設計人員可以對網站有較低的信任度（他們不能過多地混淆基礎，儘管他們可以將演示文稿改爲與DoS會有，所以不要惹惱他們）;如果你不關心安全性，PHPTal和其他人幾乎以「本地」速度運行。
至於我的工作的解決方案，我有兩個建議：
制定projectwide文件夾結構和命名約定，並堅持下去。鑑於您的業務邏輯文件的名稱，我應該能夠告訴您演示文件是什麼，反之亦然。
在業務邏輯和表示之間有一個明確的接口規範（再一次，文本文件或Wiki條目是你真正需要的）。瞭解哪些變量可用，以及他們應該如何（程序員）/（設計師）格式化，使得他們在一年之後必須維護頁面時非常高興。
是的，但只限於它們儘可能接近原生HTML。
Dreamweaver模板（忽略編輯器）基本上完成了這個很好，因爲他們基本上用一些HTML註釋來標記普通的舊HTML（POH ™）頁面。