我认为对于设计师和前端开发人员来说,大多数模板引擎很难使用,而程序员则要负担维护它们的负担.
在设计人员更新html样机之后频繁更新模板是一场噩梦,因为您的模板不再与原始html兼容.
I had this problem for very long time,最近我有一个idea,但是我不知道我是不是在重新发明某些东西,还是存在更好的东西.
>您的业务逻辑变得非常清晰.在没有混合HTML标记和表示逻辑的情况下,代码占用的空间只有½,而维护时间少于½.可以通过在两者之间指定一个正式的接口来减轻维护代码和表示之间的链接的负担,甚至可以将它们指定为文本文件或Wiki注释,其中列出了表示层需要提供的所有变量和值.
>经常根据设计者的更改来更新模板,这意味着您的表示层应细分为各种“块”,例如菜单块,页面布局块和内容块.在大多数页面上,只有内容块不同.当使用CSS和其他现代网络技术进行适当划分和实施时,合理的设计更改将对您的演示文稿代码产生最小的影响.
> CMS进一步自动化了此过程,现在从一致性和易用性的角度来看,甚至5-10页的站点都可以从使用CMS相对于手动编码的HTML中受益.
>代码安全性-Smarty不是PHP,因此您的设计师可以在站点上获得较低的信任度(尽管他们可以使演示文稿达到与DoS相同的效果,但他们对基础知识的了解不多,所以无论如何都不要惹他们)；如果您不太关心安全性,则PHPTal和其他产品几乎以“本机”速度运行.
>开发一个项目范围的文件夹结构和命名约定,并坚持执行.给定您的业务逻辑文件的名称,我应该能够告诉您演示文件是什么,反之亦然.
>在业务逻辑和表示之间有明确的接口规范(同样,您真正需要的是文本文件或Wiki条目).知道哪些变量可用,以及它们应该如何(程序员)/如何格式化(设计师),这使他们两个在一年后必须维护页面时都非常高兴.
