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