模板给我带来了什么？一点疑问，请大家论论

用xml更好模板是为了,开发时,
方便分离美工和程序,
用xml可以
分离显示层和数据层

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

参考:
http://www.phpe.net/articles/384.shtml
超越模板引擎
http://www.phpe.net/articles/384.shtml"模板引擎的要点是把你的业务逻辑从你的表现逻辑中分离出来，而不是把你的PHP代码从HTML代码中分离出来"
您举的混编代码的例子无论是运行效率还是开发效率都要比Smarty高！况且Smarty也是将处理程序与模本文件重构为混编代码程序的为模板而模板是无意义的
虽然我不是模板的推崇者，但是模板在某些方面带来的好处是不言而誉的补充一点：你的混编代码例子与编译型模板的编译结果已经十分接近了
类似问题似乎已经有很多了，hehe.
回楼上 xuzuning(唠叨) ，其实我认为no_smarty并不是混编，因为在没有用smarty之前，我们的研发队伍就是这么与美工分开合作的，回复人： zairwolf(君子兰) ( ) 信誉：75  2005-06-02 23:31:00  得分: 0
   用单一的一个小程序来评论一个模板系统的好坏，是不客观的。
  这个我知道，我其实上面两个例子可以看得出，其实都可以实现业务逻辑与表示逻辑分离，不是吗？也可以实现开发与美工分离，我想说的是，在这一层面上，其实两者都是使用模板，无非美工学习的不是smarty或某一种模板，而是直接使用PHP的几个简单语法罢了，因此，我想不出用smarty的必要性，我完全直接使用PHP就可以实现分离，那么，smarty是否多此一举呢？
看看smarty生成的实际PHP文件，实现的还是no_smarty.htm的代码，只是更复杂了<?php /* Smarty version 2.6.9, created on 2005-06-02 18:47:58
         compiled from test.htm */ ?>
<HTML><HEAD><TITLE> New Document </TITLE><META NAME="Generator" CONTENT="EditPlus"></HEAD><BODY>a:<?php echo $this->_tpl_vars['a']; ?>
<hr>b:<?php echo $this->_tpl_vars['b']; ?>
<hr>c:<?php echo $this->_tpl_vars['c']; ?>
<hr><?php unset($this->_sections['item']);
$this->_sections['item']['name'] = 'item';
$this->_sections['item']['loop'] = is_array($_loop=$this->_tpl_vars['arr']) ? count($_loop) : max(0, (int)$_loop); unset($_loop);
$this->_sections['item']['show'] = true;
$this->_sections['item']['max'] = $this->_sections['item']['loop'];
$this->_sections['item']['step'] = 1;
$this->_sections['item']['start'] = $this->_sections['item']['step'] > 0 ? 0 : $this->_sections['item']['loop']-1;
if ($this->_sections['item']['show']) {
    $this->_sections['item']['total'] = $this->_sections['item']['loop'];
    if ($this->_sections['item']['total'] == 0)
        $this->_sections['item']['show'] = false;
} else
    $this->_sections['item']['total'] = 0;
if ($this->_sections['item']['show']):            for ($this->_sections['item']['index'] = $this->_sections['item']['start'], $this->_sections['item']['iteration'] = 1;
                 $this->_sections['item']['iteration'] <= $this->_sections['item']['total'];
                 $this->_sections['item']['index'] += $this->_sections['item']['step'], $this->_sections['item']['iteration']++):
$this->_sections['item']['rownum'] = $this->_sections['item']['iteration'];
$this->_sections['item']['index_prev'] = $this->_sections['item']['index'] - $this->_sections['item']['step'];
$this->_sections['item']['index_next'] = $this->_sections['item']['index'] + $this->_sections['item']['step'];
$this->_sections['item']['first']      = ($this->_sections['item']['iteration'] == 1);
$this->_sections['item']['last']       = ($this->_sections['item']['iteration'] == $this->_sections['item']['total']);
?><?php echo $this->_tpl_vars['arr'][$this->_sections['item']['index']]; ?>
<br><?php endfor; endif; ?></BODY></HTML>
超越模板引擎
http://www.phpe.net/articles/384.shtml
楼上推荐我看这篇的同学多谢谢了，不过我不知道楼上几位是否认真看过？我原来就看过了，只是不认真，今天重新拜读了，才发现作者的想法也是用PHP语法来做为模板，原文某段引用如下
---------------------
别样的解决方案
我主要要鼓吹的一个解决方案是一个使用PHP代码作为它的原生脚本语言的"模板引擎"。我知道这以前有人做过。而且当我第一次看到的时候，我想，"为什么要这样做？"，然而我在考虑过我同事的论据之后，并且实现了一个直接使用PHP代码仍然实现了把业务逻辑和表现逻辑分离的最终目标的模板系统时（只用了大约25行代码，不包括注释），我意识到了好处所在。
-------------------
准备再看第三遍
谢谢楼上的几位，其实我发这个贴，是想让高手们帮我解疑答惑，说服我用第三方的模板而不是用PHP语法的模板，因为我总觉得没有必要
你的no_smarty不也是使用了模版么？只不过没用smarty而已。否则html文件怎么会允许
“<hr>
<?foreach($arr as $v)
  echo $v."<br>";
?>
”
这种形式呢？模版的作用是把商业逻辑和数据展示层分开，而混编做不到这一点。
而且，实际上smarty的tpl文件是经过编译的。执行速度无疑会快很多。smarty还提供cache，设置数据格式等很强大的功能，能够省略很多繁杂的劳动。也使程序看上去结构、层次更加清晰，这是不采用模版而单纯混编所做不到的。
1、从“回楼上 xuzuning(唠叨) ，其实我认为no_smarty并不是混编，因为在没有用smarty之前，我们的研发队伍就是这么与美工分开合作的，”可以看出你并不理解“混编”含义，这与是否用smarty根本是风马牛不相及
2、“其实我发这个贴，是想让高手们帮我解疑答惑，说服我用第三方的模板而不是用PHP语法的模板”
我想没有人会强迫你使用任何形式的“模板”下面讨论一下实际的问题
****************
no_smarty.htm
****************
<HTML>
<HEAD>
<TITLE> New Document </TITLE>
<META NAME="Generator" CONTENT="EditPlus">
</HEAD>
<BODY>
a:<?=$a?>
<hr>
b:<?=$b?>
<hr>
c:<?=$c?>
<hr>
<?foreach($arr as $v)
  echo $v."<br>";
?>
</BODY>
</HTML>
1、这种格式的文档同时包括html和php两种语言构件，这就是所谓的“混编”
2、你们的这种书写格式存在着一定的问题，一旦某个程序员想在其中加入xml成分时标记<?xml ... ?>就会带来极大的麻烦
3、这种格式的另一缺点是。当程序中将“模板”中的变量移做他用时，会产生不可预料的结果
回 bingofei(bingo)
我是使用模板，也知道模板带来的便利，只是既然PHP可以实现，且效率也高，那smarty、PHPLIB之类的模板有什么存在的必要？
你所谓的php可以实现，在no_smarty这个程序中仅仅表现为php通过模板来实现，而不是单纯的用php实现。如果单纯用php,就不可避免的需要在php程序中处理html乐。
使用模版和不使用模版之间的利弊就无需讨论了。
而至于使用哪种模板，到底是smarty，还是phplib，或者你如上在no_smarty中所使用的模板的方式。查一查smarty或者phplib的是用手册，其中基本都有很清晰地说明了。你看看smarty手册中的前言：纵观现今存在的许多php模板解决方案,大多数都只是提供了用模板取代变量和将动态区块的功能有限的格式化的基本方法.
但是我们的需求比这个要高的多.
我们完全不想要php程序员去设计html页面,可是这又是不可避免的.
例如:如果美工想要在动态区块之间交替不同的背景颜色,他就可能得和程序员预先说好.
同样,美工们也应该有自己对于页面设计的配置文件,这同样可以通过变量把他们拉到模板里边去.
继续. 早在1999年后期,我们就已经开始为模板引擎写说明文档.
在完成这个文档之后,我们开始用c写一个模板引擎,并有希望被包含到php里去.
在撞上了许多的技术难题的同时,"什么是模板应该做的,什么不该做"这个问题,也被热烈的讨论着.
从这些经验,我们决定应该用Php将模板引擎写成一个类,让任何觉得合适的人使用它.
所以我们写了一个引擎,从此就有了smarty.(注:这个类以前从来没有公开发表过)
这个类几乎达到了我们所有的要求:
常规变量替换, 支持包括其他模板,使用配置文件集成设置, 嵌入Php代码,限制'if'语句的作用,还有更多的可以多层嵌套的健壮的动态区块
它用常规表达式做到这一切,于是代码变得相当..,我们可以说:令人费解的.
在每次调用的时候,都要去解析那些语法和常规表达式,于是在大型应用的时候,它显然慢了下来
在程序员的眼光看来,最大的问题还是使用php脚本建立和处理模板和动态区块的所有必要工作.
我们应该如何使他变得更简单?
我们可以想象smarty应该有怎样的最后表现.
我们知道php代码如果没有了模板解析的开销将有多快,
我们也知道从一般的美工看来php语言是多么的"恐怖",
然而这一切可以被一种更简单的模板语法掩饰掉.
我们应该怎样把这两种方法的长处结合起来?
于是,Smarty诞生了....
我们开始用c写一个模板引擎,并有希望被包含到php里去
我正想用C做一个php扩展。
然后C扩展在取得php变量后输出，就是想变量赋值后不用php去解析模板文件。
而是读取C扩展编译好的内存文件。
然后直接返回结果给php，或输出。
现在的模板引擎是把模板编译成一个php文件。然后再让php解析这个文件。原理有点像这样。
打个比方，如要编码一个字符串。可以直接用MD5()函数。
也可以用php编写一段php程序实现MD5()函数.是不是直接使用MD5函数快点
建议你参考一下 DedeCms 的模板系统,你就知道为什么要用模板了
我习惯用smartemplate，那个比smarty我感觉易用。smarty太庞大了。
有没有那位大侠能介绍一下smartemplate的使用方法