Heim >php教程 >php手册 >PHP资源模板模板终结者

PHP资源模板模板终结者

WBOY
WBOYOriginal
2016-06-21 09:05:331725Durchsuche

模板|终结者

“曾经有一份珍贵的模板摆在我的面前,我没有珍惜;直到别人都在用了,我才后悔莫及!
如果上天能再给我一次机会,我会对这个模板说三个字--我用你。如果要问我用多久,我希望是
--一万年。”
        --《模板终结者》题记

第一回 E时代群雄逐鹿,侠骨柔情英雄路

第一次接触"PHP模板技术"这个字眼,是在一则介绍PHPlib的模板类的书籍上面。由于当时我水平有限,
无法理解那个template类的代码,所以一度跳过那一章,懒得去理解,眼不见心不烦。

后来我的一个朋友向我请教关于模板的问题,我脑海中这才想起是有这么个印象,所以我借故很忙,答应有空再帮助他...紧接着我就找到了那本书,仔细的阅读起来.

那是一个PHP模板类,名字就叫template,是PHPlib的一个独立部分.它使用"assign"方法指派变量,而核心功能,也就是"变量替换"则是靠"preg_replace"这个PHP函数完成的。我很快理解了它的原理。

我当时的感觉是什么?我感觉很兴奋!是的,第一次把PHP和HTML分离开来,这是一种新奇的感觉!我忍不住露出开心的微笑,并“嘿嘿”了两下--与此同时时,我发现旁边一个PLMM用奇怪的眼神看着我,所以我得意而挑逗的说道:“看什么看?没见过帅哥啊?哈哈”

然而这种快乐的感觉如同恋爱的甜蜜一样,也会很快消失;所以才过去一天,template模板类就让我感觉不舒服了。

最不爽的就是assign这个'动作'了.每次都要'指派变量',这个还不算麻烦,麻烦就在于每次都要输入"某某对象->assign"这几个字母。我很讨厌单调而毫无创意的重复劳动,所以若要形容template模板类,那就是一个字'烦',两个字'烦烦',三个字'烦烦烦'。

你也许要问,如果你不assign指派变量,那你怎么知道哪些'变量标记'需要替换呢?当时我的直觉就告诉我:“PHP变量本身,就是最好的‘变量标记’”.如果我们直接给PHP变量赋值,不是更直接更方便么?何需那几个多余的“某某对象->assign”的枯燥字符?

所以我想的是,如果能够直接用“给PHP变量赋值”的方法来指派变量的话,那该多好啊,而且还可以美其名曰:“变量赋值法”。然而当时我不知道怎么来完成这个小小的功能。

时间一天一天过去。在一个细雨蒙蒙的早上,在一个不其眼的角落里,我发现了一个东西--那就是"

传说中的"

$title="this is title";
$text="this is text";

echo

$title



$text,you can use "quote" without "\"

EOT;
?>

其中"EOT"表示"End of Template",与PHP或者C语言中的"EOF"符号命名方法类似,因为EOF表示"End of File"。你可以选择其他符号代替EOT,其效果是一样的,它只起一个标志作用,其间的任何变量若与本页上面的变量一样,则直接替换成变量的内容--这是一个很有用的特性。

为了便于叙述,我和大家约定:从echo

heredoc只起输出显示作用,属于MVC中的view层。这让我想起一个忽悠人的词语,叫做"显示逻辑"。
什么叫"显示逻辑"?英文翻译为"view logic"。其实很容易理解,就是"见人说人话,见鬼说鬼话".

例如:
$title="this is title";
$text="this is text";
$who="girl";


if($who=="PHPer"){

echo

$title



$text,you can use "quote" without "\"

EOT;
}

else if($who=="girl";){
echoHi,$who,I love you~~
EOT;
}

?>

从If开始到结束为止的代码,都属于"view logic",也就是“显示逻辑”.简单的说就是处理显示,也就是“输出”,也就是使用“echo”。既然如此,为什么要在“显示”后面跟个“逻辑”呢?因为我们要
"见人说人话,见鬼说鬼话"!如果"见鬼说人话,见人说鬼话",那么你在鬼面前就‘显示’为人,在人面前就‘显示’为鬼了。

若你是个彻头彻尾的唯物论者,你坚定这个世界上根本没有鬼,换言之你的“view logic”也就很简单,这样的话直接使用heredoc就可以了,不必在heredoc之前用if,else,for,foreach等等'逻辑型控制符号'.

为了便于叙述,我把只使用heredoc而不使用任何‘逻辑型控制符号’的代码,叫'simple view'.相反,若在你的heredoc之前使用了任意一种‘逻辑型控制符号’,则表示你使用了'complex view'.

"simple view"可翻译为"简单视图",相应的'complex view'可翻译为"复杂视图"。之所以称为“复杂”,是因为我假定这个世界上的人不总是勤快的,不总是聪明的,时间不总是充裕的,性别不总是相同的,所以某些人看上去会觉得它非常的复杂。

对于美工来说,她最喜欢'simple view'.她不但头脑简单,而且身材窈窕,bo大无脑,感情用事,毫不考虑逻辑。她名叫“小美”,艺术细胞发达,多才多艺,能歌善舞,设计的网页优美多情,引来无数仰慕者欲吐衷肠,无奈不会做“留言本”--所以她找到了程序员'小程'。

对于程序员'小程'来说,他最喜欢'complex view'。只有'complex view',才能引起'小程'的兴趣,才
能体现其'英雄'的形象。他是现实中的韦小宝,他八面玲珑,见风使舵,也就是会使用"If语句和switch语句";他出口成章,滔滔不绝,也就是会使用"For语句和while语句"等等。他在皇帝面前显示为“忠臣”,在朋友面前显示为“仗义”,在美女面前显示为“多情”。如果他不使用'complex view'的话,是绝对不能满足如此复杂的需求的--所以在美女面前,他也就算得上是一个英雄。既然只听说过"英雄救美",没听说过"狗熊救美"的说法,所以小程与小美便自然而然的相遇了。

小美名如其人,所以小程很快就被小美迷住了。想当初,小程又当‘程序员’又当'美工',虽然能够完全胜任程序员的工作,但对于‘美工’之类的事情,一直颇为自卑。尽管如此,小程却也能够得心应手的处理‘两者’的关系--他在美工方面要求自己使用简约明快的风格,从而扬长避短,同时自己又对程序游刃有余,所以‘又当爹来又当妈’,虽然有点累,但由于一切都在自己的‘掌控之中’,所以反倒觉得比较‘顺手’。

如今见到了小美,才知道原来世界可以如此美丽。他不禁感叹:这个世界不但有+-*/,原来还有红色的花,绿色的草,小鸟在唱歌,蝴蝶在跳舞。。。这是因为小美在播放自己的flash作品,小程看的眼睛都直了。刹那间,倾慕之情便油然而生,即便小美叫他去死,他也再所不辞...正在小程心猿意马之时,小美柔声说道:“小程哥,小女子早就听说您的PHP大法威震武林,在这个群雄逐鹿的E时代,能够与jsp,asp.net三足鼎立,实在非英雄莫属。。。”小程立刻心花怒放,激动的话都说不出来了。小美接着
说道:"小女子其实有一事相求。原本打算找Microsoft帮忙,因为听说他资产雄厚.谁知道他却是个吝啬鬼,小气无比,说什么他的东西只能够在他的地盘上使用,不允许踏出他家的后花园。我一听肺都快气炸了,发誓要找一个慷慨的朋友帮忙。于是经人介绍,我找到了java。java他确实是个非常慷慨的朋友,一点也没有Microsoft的小气和吝啬,这点我道是比较满意。但是每当我看着他蹒跚的步伐,听着他慢吞吞的声音,想着他还是个超级大胖子,我的心里就感到不舒服。也许是java看出了我的心思,所以他知趣的和我告别了。临别之时,他对我说‘我有个同父异母的兄弟,名叫PHP,他3,4岁的时候非常瘦,我对他有偏见,所以很讨厌他,但最近我收到他5岁的照片,发现他变强壮了,这才对他有了点好感。小美,你可以去找找他,看看行不行。哦,对了,PHP是他的绰号,他真名叫小程’。告别了java,于是我便找到了您。。。”小程禁不住沾沾自喜,得意洋洋,于是说道:“能得姑娘赏识,实乃三生有幸。姑娘有什么事尽管开口,在下一定全力以赴,绝不会让姑娘您失望。”

就这样,小美希望小程帮忙做一个‘留言本’.这个留言本除了基本的功能外,还要提供十种不同的显示
风格。这些不同的风格主要由小美负责完成,由于工作量巨大,小美把她的弟弟‘小工’也叫过来帮忙。而小程则负责数据处理,编写程序。

这就存在一个问题:小程希望实现业务逻辑和表现逻辑的相互独立和分离:

1.php业务处理与html页面显示相互独立(不排斥在html中使用php标签);
2.可以预先直接预览HTML的页面效果;
3.预览时,页面之间的链接关系可以看到,就象一个不懂程序的设计者做的网站,全是静态页面,但这些静态页面之间的关系是清晰的;
4.速度要过得去。

这就是小程提出的“模板引擎四项原则”。想起这些原则和要求,便让他联想起那天晚上他与他弟弟“小序”之间的对话。小程清楚的记得小序曾经说过:
“我一直没有采用任何模板技术,因为我从来没有发现哪一种模板适合我,phplib、smarty、supertpl等等,通通都不适合,想自己写,水平不够,也没时间和精力。

让我讨厌这些模板的原因是,它们不能展示界面的原形或者说是原貌!我们公司目标客户都是中小型的,这些客户总是要求在程序未实现前能够看到所有的网页界面,所以,公司基本上都把重点放在美工上,而对程序并不是很重视,这就存在一个很大的问题,由于每个设计者的风格不一样,导致交到我手里的界面风格千奇百怪,很难做到“批量”处理,实在很累!更糟的是,除了个别设计者对程序有所了解外,其他的简直是一窍不通,几乎每次我都要先把他们的界面修改一下才能嵌入程序,我一直在寻找一种简单又好用的模板技术,能够在前期预览效果,如界面颜色、版式等,不让设计人员花太多的时间就能学会(他们根本不愿意花时间学),也就是这种模板与他们平时设计的网页基本没什么区别,但我一直没看到这种模板技术,实在让人失望! ”

确实,小序的失望也让小程颇有同感。正在思虑之际,忽然传来一个声音:“嘿,大哥,在想什么呢?该不会是在想如何泡MM吧?呵呵。。”来者是小程的三弟,名叫‘小员’。“去去去,你大哥没你那么
风流,从早到晚都想着泡MM...”“哪你想什么呢?想得那么出神?”于是小程把事情的经过一五一十的
告诉了小员。

不料这小员很是生气,竟然用英语说道:“php really need these fucking template engins? No!
Do not waste your time. Pay your time into your business requirements. ”

小程问道:“你叽里咕噜一些什么呢?”小员说道:“我的意思是说:php最好的模板语言就是php本身。你没有必要去选择诸如smarty之类的这种食之无味,弃之亦不可惜的东西。”

小程道:“照你这么说,php最好的模板语言就是php本身,那么你的这个模板能够满足我的模板引擎四项原则么?

1.php业务处理与html页面显示相互独立(不排斥在html中使用php标签);
2.可以预先直接预览HTML的页面效果,包括图片;
3.预览时,页面之间的链接关系可以看到,就象一个不懂程序的设计者做的网站,全是静态页面,但这些静态页面之间的关系是清晰的;
4.速度要过得去。

小员一时语塞。他心想:“记得smarty刚出现的时候我也曾是个鼓吹者, 所谓的自己的模板类也写过不少, 公司里现在还是2种方式并存, 另一种用的是改了很多很多的smarttemplate, 不过现在已经基本停用了. 当年用smarty写完一个论坛以后, 我就发誓再也不用这种垃圾东西了. 于是第二次写论坛的时候是xml+xslt.见过形形色色的模板引擎模板方案,使我坚定一个正确的结论,那就是‘php最好的模板语言就是php本身’然而要说到完全满足上面的模板引擎四项原则,几乎没有人做到过。即便是用php本身作为模板引擎,也是如此。”

这时手机铃声响了起来。。。小员对小程说道:“公司有事需要我去处理,我们下次有空再聊这个话题。哦,对了,你可以去和我的一个朋友axgle谈谈,据说他对这个话题比较有兴趣也很有心得,你不妨去找找他。拜拜。”“喂,别跑啊,他的QQ号是多少啊。。。”“380139552——”

欲知后事如何,且听下回分解——

第二回 资源模板横空出世,华山论剑再起风云

话分两头。却说这axgle正打算写一则有关模板的文章,忽然看到有人加自己的qq。只见附加消息中写着
“小员的朋友”,于是接受请求,开始聊天。

“您好啊Axgle,听闻您的大名,如雷贯耳哦。”
“阁下是?”
“在下是小员的哥哥,名叫小程。听闻您对PHP模板颇有研究,所以特来取经,还请您多多指教”
“客气客气。研究谈不上,不过是略有心得。大家互相讨论,互相学习最好啦”
“那么,您对‘模板引擎四项原则’作何看法?”
“哈哈,真是英雄所见雷同啊!哦,不好意思——是英雄所见略同”
“那么Axgle您对此有何高见,从而能够实现这个目标呢?”
“不瞒您说,我正在为此写一篇文章,名叫《模板终结者》,在详细的讨论这个问题。”
“不知现在您完成了多少,真想先睹为快。。。”
“呵呵,目前正写到第二回‘资源模板横空出世,华山论剑再起风云’,到你现在看到的这句话为止,包括句号和引号。当然后面的引号你看不到,因为QQ中一般不打引号。”
“知道了。那为什么第二回是这个标题呢?”
“因为第二回我会向大家介绍‘资源模板’的来龙去脉;另外,我的网名叫‘华山论剑’,而你叫‘再起风云’,所以这样以来便可以给读者一个完美的交代。”
“原来如此。您真是幽默啊,把大家忽悠的团团转。”
“罪过罪过,南无阿弥陀佛。。。出家人不打诳语。请容在下详加解释,也请大家洗耳恭听。”
——1.PHP资源模板是什么东东?

这里的‘资源’,是指用来创建网页的各种辅助元素,例如各种图象,js脚本,css样式文档等,同样也可以包括flash中的swf文件等等,诸如此类的‘可连接的非HTML元素’。


‘资源’通常都是‘通用性’的,可以反复出现。例如同样一幅图象可以在各种不同的页面出现。因此
所有的资源文件,都可以放到一个文件夹中。我们不妨把这个文件夹命名为“assets”。

在assets文件夹下,为了便于区分和管理,可以按照种类的不同新建各种不同的文件夹,例如images,
javascript,css,flash等等。其目录结构如下:

assets:
    |-images
    |-javascript
    |-css
    |-flash

这样的目录结构是清晰而有序的,不至于让一切变得混乱不堪。

我们把任何html文件放到与assets同级的目录中,你一定同意这是理所当然的事情:
例如:

index.htm
register.htm
post.htm
...
assets:
   |-略


因为这样一来,所有的路径可以使用相对路径,能够直接与assets中的资源文件建立‘连接’。

例如index.htm中需要一个Logo图片,其路径为‘assets/images/logo.gif’。

我们规定这些HTML文件与assets一道,统称为‘视图文件’,或者称为‘模板文件’。为了便于
区分和管理,我们给它取个名字,例如“default”,并且新建一个default文件夹,把这些“模板文件”全部放入其中。

因为同样的数据可以有不同的显示风格,所以视图可以有多种,换言之可以有多种不同的风格。我们可以如法炮制,建立多份‘模板文件’,并且分别取个名字,与‘default’文件夹一样处理。

由于有多种不同的视图,于是我们看到的目录结构如下:
default:
    index.htm
    assets:
      |-略

other_style:
    index.htm
    assets:
      |-略

为了便于与PHP文件区分,我们可以把‘default’,‘other_style’等放入同一个文件夹中,通常取个名字叫‘template’,但我别出心裁,不遵循这一点,而是取名字叫‘view’.因为我认为‘view’比“template”更能够更好的表达我的思想。
新建一个文件夹,取名“view”:

于是其结构变成:
view:
    default
    other_style
到此为止,视图目录便大功告成了。

接下来就是PHP目录问题了。这是核心和关键,请大家仔细体会。

我们假设存在index.php文件,把它放在与‘view’文件夹同级的目录中。现在index.php从某处取得数据后,需要调用index.htm文件负责显示了。我们假设它选择‘default’风格,那么相对于index.php文件,其对应的index.htm的路径为‘view/default/index.htm’。

无论你使用什么模板引擎来处理现在的问题,你都会发现‘资源文件无法共享’。
例如在上面的情况中,logo.gif图片就无法在index.php中正常显示。因为index.php
与index.htm不在同级目录中,而index.htm文件却使用的是相对路径来连接图片。

为此您该怎么办?你可能会有如下方案来解决这个问题:

方案一:

您可能会说:“axlge你是猪头啊。你不晓得把index.php文件和index.htm文件放到同级目录中不就可以了嘛?”

如果是只有一种风格,道是可以这样做;但即便如此,把html文件与php文件放到同一个目录,也让人略有混乱之感。我认为这样并不好,因为修改起来不方便。毕竟我们希望程序员和美工能够各有各的‘地盘’,相互的关联越少越好。

所以方案一可以被否决。

方案二:

您可能会说:“axlge你是猪头啊。你不晓得把相应的‘资源文件’,例如图片复制一份到相应的目录中,不就可以了么?”

是的,这是可行的。但并不‘优美’。因为如果某张图片被修改,则相应的图片需要从新复制一次。何况有时候资源文件的数量相当庞大。而我却有办法无须复制就可以共享同一个‘资源文件’

所以方案二可以被否决。

方案三:

您可能会说:“axlge你是猪头啊。你不晓得使用str_replace或者preg_replace函数进行路径转化吗?”

是的,我晓得。但我不认为“读取文件不说,还要进行‘模式匹配’”是一件值得去做的事情。简单的说,我反对使用PHP中的任何‘replace’函数应用于模板引擎中。

所以方案三可以被否决。


最后您终于忍无可忍,冒火了:“我靠,说了半天我道是想问问:你何苦要求要在PHP和html中都能预览到图片呢?”

那是因为市面上已知的模板引擎中,其模板文件在浏览器中打开的时候,都相当的丑陋。要么不干不净,长满麻子;要么破破烂烂,衣观不整(例如图片无法显示)。

其实这个问题难倒过无数英雄好汉。我以前也写过一则文章,来解决这个问题。文章标题叫《给文件夹加上$符号》。套用这篇文章的思想,我们可以这样来解决这个难题,那就是给‘assets’文件夹前面
加上一个“$”符号。

换言之,就是使用“$assets”代替原来的“assets”作为文件夹的名字。

现在,为了理解这样做的作用,让我们暂时把注意力和视线放到美工身上。假设小美设计了一个index.htm页面,该页面包含一幅logo图片。那么这个logo图片的路径为“http://www.pushad.com/Info/$assets/images/logo.gif”
其相应的html为:PHP资源模板模板终结者。显然在index.htm中能够正常显示图片。

下面再把视线转移到PHP程序员上面来。假设小程在index.php中调用index.htm文件,在include之前,定义一个PHP变量,名字也叫‘$assets’.代码大体如下:

$assets='view/default/$assets';//这里使用单引号,防止后一个$assets被PHP当成变量。

include 'view/default/index.htm';
...
?>

当执行上面的代码后,index.php生成的html变成了这样:

...PHP资源模板模板终结者...

因为等效的PHP代码如下:

$assets='view/default/$assets';

echoPHP资源模板模板终结者
EOT;
...
?>

上面的第三个$assets与第一个$assets同名,所以直接就被替换掉了。

前提当然是index.htm中使用了‘heredoc’。

这样以来,图片的显示问题就被巧妙的解决了。无论是在index.php中还是在index.htm中都能够顺利的
显示图片。

同理,其他javascript,js,css,swf文件也能够正常运行或显示。一切只需要“一个$符号+一个heredoc”

另外一个问题就是html文件显示的时候“干不干净净”的问题。因为index.htm中使用了heredoc,所以有php符号"echo”注释符号隐藏它。这样就显得干净了。在预览的时候,html显示的就是其‘原貌’。

最后一个问题就是:“预览时,要求页面之间的链接关系可以看到,就象一个不懂程序的设计者做的网站,全是静态页面,但这些静态页面之间的关系是清晰的”

例如:index.htm里有个超级连接,连接到register.htm.其html代码如下:
注册。这样一来就能够满足上面的要求。

但PHP这边该怎么办呢?假设存在一个处理注册的PHP文件,名叫“register.php”.那么index.php如何超级连接到register.php上面呢?

这个其实很简单,可以在PHP中输出一段javascript,让浏览器自动把超级连接修改一下就可以了。

这就是全部。如果文字叙述不能够让你理解,您可以参考后面附加的演示文挡,那么一切都会显得很简单。

第三回 要简单还是要复杂,这不是问题

有人说,在模板文件中嵌入PHP代码,这对于美工人员来说‘太复杂’了。即使我上面介绍的资源模板已经为美工人员考虑的比较周到了,但还是会有一部分人心里会觉得不舒服。

我虽然是仁慈的,但‘现实’却是残酷的,这句话的意思是说:不使用循环语句,你将无法批量输出。你一定会表示同意。但你依然会争辩说:“为什么不可以在html文件中把批量输出的部分用一个变量来代替,然后在php中为这个变量赋值呢?例如一个表格的填充,在PHP文件中生成表格不就得了”。

你当然可以那样做,但你却违背了“可预先预览”的原则。表格的字段名称最好是在html中能够直接显示出来,以便能够更加直观的反映网页的输出目标和意图。

所以请你不要介意在html文件中插入的少许控制流程的PHP代码。

但基于MVC的要求,html文件中不应该存在数据分析和处理的代码(例如连接数据库),换言之html模板文件只负责“显示逻辑”,而不要管其他任何事情。当然在简单的应用中,你可以使用‘simple view’,里面的PHP代码就最少,往往只有一个'heredoc'。

诚如‘小员’所说:“PHP最好的模板语言就是PHP本身”。而‘PHP资源模板’可以说是很好的贯彻了这个思想。不但如此,更是巧妙的实现了“模板引擎四项原则”,可以说是‘前无古人,后无来者。念天地之悠悠,独苍然而泣下’——不要误会,那是‘高兴的眼泪’。

所以不管是简单还是复杂,PHP资源模板都是最棒的,它就是传说中的‘模板终结者’,“只要有了它,你的一生都会改变,在你使用它之前,我要提醒你,尘世间的任何其他模板,你都无须再有半点留恋。”

“曾经有一份珍贵的模板摆在我的面前,我没有珍惜;直到别人都在用了,我才后悔莫及!
如果上天能再给我一次机会,我会对这个模板说三个字--我用你。如果要问我用多久,我希望是
--一万年。”



Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn