有谁知道一种模板类可以支持模板的预览的？

Question

希望网页设计人员可以通过Dreamweaver的站点设置直接调整并预览模板。
有谁知道哪种模板类可以满足这样的需求吗？

Answer 1

{include file="footer.tpl"}如何处理？类似{/if}{sectionelse}这些东西怎么隐藏（不隐藏会破坏页面结构）是要给设计人员看的，不是程序员用Dreamweaver看。

Answer 2

http://jssmarty.googlecode.com/http://jsmarty.googlecode.com/Ps.我用的就是上面那个作者的马甲：）

Answer 3

多嘴说一句哈，感觉smarty像脱裤子放屁，多此一举smarty我只简单用过，对比phplib的好处个人觉得它也就是在模板缓存上。上面那位说的jsmarty可能又让它多了一个预览的优势。但其它的就感觉不到了。。学起来麻烦，因为它自己引入了很多关键字；html处理麻烦，如果要显示{}等字符又要特殊处理；本来目的是MVC，结果smarty里面自己搞了什么日期选项菜单生成啥的，M把V强奸了这个可能是我见识浅薄啦。。如果是我的理解误区，还请指正哈~
这么多模板，引入了很多特殊符号，{}，{/if}.....为啥不直接用php自己的<??>if foreach ......呢不就是在模板中加入控制流么。。

Answer 4

我来顶smarty的，不是顶楼主，既然楼主只是简单用过，就不要对smarty评点太多了

Answer 5

因为模板是给美工修改的。直接使用php的<??>那美工人员不是想干嘛就干嘛了？一个自作聪明的“手误”可能引起大灾难。
smarty里美工爱怎么搞怎么搞，最多只能让显示出问题，修改不到数据。
如果你写代码兼作美工的，请选一个轻量的模板类。smarty不是为轻量级准备的。

Answer 6

就因为这个就要这样做么？你的这种说法在smarty官方文档中看到的？而且我觉得没有必要吧。。如果你担心美工是个hacker，那你大不了专门写个比对程序，把美工提交的模板与原模板比对，看看php代码部分是否有被修改不就完了要是smarty的作者就是因为这个才做得smarty那也太扯了吧至少我不认为这需要在模板内部实现，完全是外部检测工具可以做的事情，干嘛塞到模板里。
一种框架思想，一种技术规范 我觉得才是最重要的。再加上一组方面快捷的外部工具加速开发工作，这就完美了。smarty就是为一部分公司量身定做的，用了它解决了这些公司的很多麻烦，也规范了公司内部开发。但同样的对于程序员来说，他的思维被固化，缺少了深入的积极性，学会了使用一个高级工具，却失去了对更深层次知识的理解。授之以鱼不如授之以渔，与其用smarty还不如总结一套经验，阐述适合自己的一套框架思想，采用一种适合自己的技术规范，搜集一套适合自己的辅助工具。对全部开发人员进行这方面的培训，不是比让开发人员学smarty更好？仅仅是因为没有多少公司有这个经历和人力创建这一套东西而已，而smarty是有专业团队维护。为什么我们不能来维护一组适用于不同要求的框架思想，技术规范，辅助工具，而不搞这些固化的东西呢？

Answer 7

这种东西有那么好么？html的发展趋势是向xml靠拢的，web也是向dhtml发展的。
而MVC如果用xml来理解的话也是 模型与视图坐在一起商定一个schema，然后模型按照这个schema输出数据给控制器与视图，然后通过控制器控制视图显示、更新。那么俺想问，smarty对这个支持的如何呢？ 它是这样做的么？所做的能得到大家的一致认可么？
我觉得它是没必要的。
我们现在需要的是哪个神人像 从C时代把我们引入C++时代一样，把我们从php，asp，jsp...时代引入一个新的时代。那才是我们需要的！
像smarty这类不够成熟和完善的东西，我个人觉得，用多了反而影响技术掌握，而且牺牲太多的灵活度与性能。呵呵，话说的太满了，主要还是想知道大家都在用什么样的方式开发，想总结出适合自己的一种开发模式。

Answer 8

我只是告诉你为什么引入这些特殊符号而不是直接用php自己的<??>而已，我可没说过smarty的作者就是因为这个才做得smarty。正如C里的指针一样，为什么后来的语言大多数都不实现指针。三个字：太灵活。

Answer 9

to yh801216:
1 对于smarty的一些内置函数,灵活应用可以起到很大的作用.
  如果开发双语网站或者多语网站,各个国家的日期显示都有差别,而smarty的日期时间函数,就可以直接在终端以不同的形式来显示,这就避免了,你在将数据传给模板之前分别处理.你只需要处理日期时间函数的参数就可以了. 其它比如字符串函数,条件语句等等. 适当增加一些显示逻辑,能够减轻C和M的负担. C和M只需要提供数据就可以,至于怎么显示,显示成什么样子,不需要管. 这也是分层的原因之一.
2 smarty内置html函数.比如说下拉框.将下拉框数组和选中的项传给smarty函数,其它的就不需要操心了.
如果没有这个函数,势必你要自己完成这个循环,或用php或用js. 
3 你说的{}这个标签,如果觉得可能引起冲突,可以自定义. 

Answer 10

分享一点个人经验吧！
我原来用的也是smarty
后来感觉有点不便，因为如果我在循环中，想使用一个自定义的函数时不，不知如何定义，也是smarty了解不多的原因吧后来比较了一下uchome的模析和codeigniter的模板和ruby-on-rails的模板后来还是选用了ci的形式，用一数组住视图VIEW中传参数！，另外，采用函数方式，所有公共函数均可在视图中使用，很方便，也不用编译！模板名采用了ruby的方式（a.html.rb)，如a.html.php!这是最简单实用的实现视图分离的！不过确实有一个问题，就是在ＶＩＥＷ中，在<? ？>中，美工人员可以进任何ＰＨＰ操作！这个问题好像uchome也没解决的！因为他只是进行替换标签！这个问题应该可以解决，就是在解析时替换掉mysql的相关函数或其他函数如果模板（视图）是类解析的，那么他调用外部函数可能就是个问题？
如果是函数解析的，调用外部函数和全局变量就不是问题！有人说uchome的模板解析是轻量级的，而ＣＩ的显然更轻量一些，当然，如果用函数解析不用模板，只是调用视图，可能要更轻量一些！连模板解析编译的过程都给省了！

Answer 11

呵呵，看到这么多人回复，很感谢大家。
如果伤到谁的自尊了，我道歉，真诚的道歉。因为我有时一样会因为类似的事情有这样的感觉，所以我觉得道歉是必要的。呵呵，不过我并不高傲，仅仅是一点点对于smarty的排斥+讨论问题时的执着吧。（曾有朋友说我讨论问题像吵架呵呵）另外，说到 显示效果的兼容性以及多语言，时差等等的问题，它们确实是V的问题，也确实不应该由M来做。
对于大多数应用，如果smarty一直保持良好的支持，那么我相信大多数人都会选择它，也包括我。有时我只是讨厌不管什么应用，大家上来就推荐smarty。 那样还有意义么? c太灵活，那是不是它就没有存在价值呢？恰恰相反吧？之所以反感什么都是smarty就是因为它不是万能的，而很多人却把它当成万能的。。呵呵，轻量级的，超轻量级的，用别人提供的时候总有这样那样的问题，原因很简单没有足够的技术支持，没人维护。之所以希望有人维护一种思想，一种理念，原因就是这种思想与理念才不是随便过时的，把它实例化时你可以用任何一种你希望的形式。让V自己完成各国时间日期差别么？简单，定个规则支持就是了，就好像定义一个数据类型或者是定义一个数据预处理方法、函数一样。当然，这样在一些大型应用中确实不如用smarty，因为这就像用C些界面一样，痛苦。但是，同样的，如果要求你用php，而又需要尽可能的提高性能的时候，你如何选择呢？有时你不得不选择这样痛苦的事情吧:) 也许很多人说既然痛苦干嘛还去搞呢？ 类似问题参照C或者汇编就知道了。呵呵用一个好的思想，理念去指导开发才是最关键的。如果一味的去借用高级语言高级功能的便利去做开发，那只能停留在表面。。我说的这种不一定非要用它，甚至可以说，仅仅是一些特殊应用才会用到它，包括我自己都可能大多数时候选择一个适合的或者沿用原有的模板技术，但这种思想与理念的意义不在这里，是在对自己技术的提高，以及让自己更深层次的理解正在用的模板技术。MVC其实理念很清晰简洁，但现有模板哪个是完全按照这个理念了？因为各种问题，为了应用的更加便捷，没哪个模板完全符合它的。 那么说MVC不好么？是不是该改改这个理念？似乎不是。 对MVC更好的理解与支持，需要技术的不断发展才行。
最后我想问与其抱着一个模板或者几个模板技术，为啥不更关心关心理论、理念上的发展呢？