作者水平有限，不能保证内容完全准确，有不正确的地方请大家帮忙指出

“模板”这个词，可能很多人第一印象是后端的技术（Smarty，Velocity等），但本文要讲的却不是后端的概念，而是前端开发中所使用到的一种技术，也就是“前端模板”技术。

模板的工作原理可以简单地分成两个步骤：模板解析（翻译）和数据渲染。这两个步骤可分别部署在前端或后端来执行。如果都放在后端执行，则是像Smarty这样的后端模板，而如果都放在前端来执行，则是我们要探讨的前端模板。

问题

随着前端交互的复杂性不变提升，无刷新页面数据传输与渲染越发地频繁化，我们发现传统的前端开发方式在ajax数据渲染等方面存在着一个主要问题：繁琐的数据渲染。当前端从后台通过ajax等方式或许到数据后，如果要将这个数据渲染到指定的dom元素中，则需要进行各种字符串拼接工作或者一系列创建元素的工作，还不论细节的问题（单引号双引号问题等），不管是哪一种形式，都是繁琐且费时的。同时，在可读性与维护性上也存在问题。试想，各种循环操作的字符串拼接，元素创建插入，在需要修改时，都需要重新花费不少时间与精力。那有什么方法可以解决这个问题呢?

原理

当我们在JSP中写<ul><li><%= name %></li></ul>的时候，其实就是在应用模板，在后台这句话会被转换成out.print(“<ul><li>”+name+”</li></ul>”)。模板的数据渲染就是把模板中的占位符（这里是”name”），替换成传入的值（比如替换成”yaya”）。而在前端开发中，这种方式依然具有很高实用价值。前端模板的核心是前端模板引擎，引擎将前端的模板语言转换成浏览器可以解析的html语言。当转换成功后，便可以很方便地将这段html代码放到我们希望的地方去。

比如我们可以写一段循环的li标签的前端模板语言。通过前端模板引擎转换后成本一连串得li标签的html语言。这时候就可以直接采用innerHTML方法把html代码插入到ul对象中，那么就完成了生成ul列表的功能。

初识

前端的模板核心是模板解析引擎，而解析引擎的主要作用是将模板语言转换成html/xml格式。不同的前端模板有着不同的模板语言，解析引擎因此也各不相同。让我们先来认识几款前端模板，了解下它们各自的模板语言。

Yaya Template是一款轻量级的模板引擎，采用原生javascript语法，具有易学易用等特点。我们来看一段用Yaya Template渲染列表数据的实例：

模板语言（通用过for循环，输出“这是第n列”的li列表）

有了模板语言后，我们只需要将数据“打入”模板语言中的”list”，就可以生成我们想要的html/xml格式了。如上例，我们只需要得到这个模板语言进行翻译，并调用对应的render方法，

这个html则是模板引擎转换成的html/xml语言，在上例中，则为：

从这个例子中，我们可以发现，{$…$}表示输出的html/xml片段，{%…%}表示输出javascript变量。得到的html，我们可以用直接作为dom的innerHTML或者其他用处。

这便是前端模板，它使得我们不必去处理字符串拼接等问题，用最直观的方式来渲染数据。我们再来看另外一款前端模板EasyTemplate。还是之前的例子，用EasyTemplate模板写法如下：

同样，需要将实际数据替换模板变量，这里采用：

像EasyTemplate这样的前端模板，是属于自定义模板语言的一种前端模板。我们可以从上例看出，””就是EasyTemplate自定义的循环条件。像这样EasyTemplate 模板一样采用自定义标签的前端模板还有 lite Template:

渲染时采用：

好了，我们再来看看jquery作者John Resig所写的一个前端模板jquery template。说真的，它如同jquery一样，短小精悍。还是老例子：

渲染采用：

我们可以看出，Yaya Template与jquery template在模板语言的写法上正好相反。前者将输出html语言做特殊标记{$…$}，而后者对javascript语言做特殊标记。这两种模板已经使得学习成本很低了，而接下来介绍的ace template的写法将更加简单易懂。

渲染采用：

ace template采用了html与js语言直接混搭的风格，在两者间可以直接的书写，不用添加任何的标志用以区分不同的语言。而在html语言里面，使用js变量则采用#{}的方式输出。ace template之所以可以兼容html与js混合写法，是通过按行解析来实现的。所以，如果代码能够保证html语言与js按行划分，这样的用法其实是很方便的。并且ace template值得说明的一点是支持自动编码防止xss漏洞，通过#{}渲染出来的javascript变量，已经经过了编码处理，这一点是很方便的。而对于不需要这个功能，需要原文输出的时候，ace template也提供了!#{}方法来满足这种需求。

通过上面对五个前端模板的简单介绍，我们可以了解到不同前端模板的各种形态，这包括写法与用法等直观印象。但我们知道，前端模板的核心是代码的转换，这肯定是需要转换时间的，那就以上五个不同的前端模板，性能上会有怎样不同的表现呢。

性能

前端模板语言到html/xml语言，是通过模板引擎进行翻译的。而模板引擎的翻译性能在某种程度上决定了前端模板解决方案的可行性的高低。上诉五种前端模板，各自的性能会是怎么样的，我们对它们进行测试。分别对Yaya Template、EasyTemplate、jquery template、 ace template、lite template部署前端模板做同样的操作，比较模板引擎翻译时间代价。

各自的模板代码如下：

Yaya Templat

EasyTemplate

jquery template

ace template

lite template

然后我们改变list数组里面的元素个数，对各个模板翻译执行的时间进行记录。结果如下(xp+ie6/ie8/firefox/chrome运行环境)：

模板翻译时间对比表(第一次翻译并渲染数据 时间单位:毫秒)

通过第一次翻译后，如果前端模板可以缓存翻译后的中间代码，或者可以返回构建中间代码的函数，那么再次渲染数据的时候，就不需要再翻译。这样可以极大的缩小渲染数据的时间，提高速度。

综合各种调研数据对比表如下：

兼容

前端模板的兼容性也是一个重要的问题。能够实现用户不同的前端模板需求，将前端模板语言正确翻译成html/xml语言，是优秀的前端模板所需要具备的特点。而通过对以上五种前端模板的测试，并没有发现严重的兼容性问题。但在一些细节上，还是发现了一些问题如下表:

兼容性测试对比表

流程

对于“什么是前端模板，它有什么特性，怎么使用”这样的问题已经通过上面的分析说明给出了答案。但前端模板既然是前端的范畴，就不可能独立存在，而是需要运用到前端开发的流程中的。而采用了前端模版的开发流程与传统的相比又会是怎么样的呢？

上图是传统的开发流程。首先将ui设计图转换成html的页面，其中的数据一般先用模拟数据代替。比如，ui设计有个列表，那么可能开发人员会先建立一些模拟的数据填充到节点中，来开发调整页面样式。最后一步，则将需要动态生成（ajax应用等）的地方，将模拟数据的节点变成空白节点，然后在javascript里面拼装这些html节点的字符串，最后再还原到原节点处（比如用innerHTML插入html）。

上图是一个实例。当列表中的元素需要ajax动态加载的时候，在传统开发中可能按照先开发模拟数据的html页面，再将这些元素拼接成html字符串，之后再进行一系列处理的功能。

那么，它的问题是什么呢？很明显，“不可逆”是最大的问题。当开发者完成了开发，这时候如果需要修改，那么将是很头疼的事。由于是由字符串拼接出来的html片段，想直接修改这些字符串来改变结构或是修改样式什么的将是一个比重新开发一遍还要具有挑战的工作。所以，开发者往往选择再来一遍吧:html的模拟数据页面，然后再拼接字符串。除了“不可逆”，维护性差以及开发成本高都是采用传统方式开发富客户端应用的弊病。

好吧，我们试着改变这个局面。看看下图，采用前端模板开发的新方式，或许会找到某些答案。

“双向可逆”，是的，采用前端模板的开发方式，在开发好展示的html页面后，直接经过简单的修改即可生成html+template 页面，无需再拼接字符串，无需再反复重写展示模拟数据的html页面，一切都变得很轻松。我们来看看代码便知道原因了（以ace template为例）。

如果调用模板引擎，当模板执行数据执行后，直接覆盖parentNode里面的内容。而如果想继续调整html结构等，则不调用模板引擎即可。而原有的调试数据，在需要发布的时候可以直接通过代码编译去掉debug start与debug end之间代码即可（这仅仅是前端模块开发的一种实例，实际开发中可以去掉模拟数据，不用编译）。

展望

前端模板技术其实还有很多的工作要做，比如模板的事件代理，模板的复用性，模板的组件库等等。本文仅对前端模板做了一个大致讲解。相信随着对于前端模板的探索，模板技术会被越来越多得运用的前端开发，特别是富客户端的前端开发中，进一步提高开发效率，为开发人员带来更多的惊喜！

参考资料

1.yaya template http://uloveit.com.cn/template

2.easy template http://www.easyui.org.cn/easyTemplate.html

3.jquery template http://ejohn.org/blog/javascript-micro-templating/

4.ace template http://blog.csdn.net/zswang/article/details/6582563

5.lite template http://code.google.com/p/lite http://firekylin.my.baidu.com

摘要

针对前端开发中基于ajax的复杂页面开发所面临的代码规模大，难以组织和维护，代码复用性、扩展性和适应性差等问题，本文尝试以MVC思想为基础，结合Web前端开发中内容-结构-表现-行为相分离的开发标准，提出一种将Web页面代码分为视图（View，页面静态部分，包括内容、结构、表现）、模型(Model，负责数据缓存、数据校验与本地逻辑处理、发起ajax请求)、控制器（Controller，负责用户和系统事件响应、模型和渲染器调度）、渲染器（Renderer，对视图的渲染，控制器与事件的绑定、数据搜集）的页面开发新模式，并基于此模式提出了一个开发框架原型。

关键字:

MCRV设计模式 Javascript MVC Web开发标准

1.Web前端开发面临的问题

早期的Web页开发(Web前端开发)中，Web页面较为简单，大多数Web页面的功能仅限于用HTML和简单样式展示静态信息，或向服务器发送数据，Web页面与用户的交互较少。随着Web的发展，DHTML、CSS、javascript等技术出现，Web页不再仅限于展示静态信息，动态、交互成为Web页的主流功能之一。与此同时，Web页代码规模也变的较大，页面中的HTML、CSS、Javascript等代码往往混杂在一起，如何很好的组织这些代码，使Web客户端程序具有很好的结构，易于阅读和维护，成为Web前端开发人员面临的一个难题。在实践中，业界提出了内容(Content)-结构(Structure)-表现(Presentation)-行为(Behavior)相分离的Web页开发标准。在这种标准中，一个Web页代码可以分为如下四个部分：

    内容：页面实际要传达的真正信息,包含数据、文档或者图片等。
    结构：对内容的划分，使内容更加具有逻辑性，易用性。类似页面的标题、作者、章、节、段落和列表。
    表现：用来描述内容外观，称之为“表现”，主要指CSS样式。
    行为：行为就是对内容的交互及操作效果。行为控制主要通过javascript实现。

内容-结构-表现-行为(CSPB)开发标准对Web页包含的的代码进行了分类，使代码各个部分得到很好的分离，使Web页初步具有了良好的结构。

随后，Web进入了崭新的Web2.0时代，以Gmail为代表的Web2.0应用大量出现，并且取得很大的成功。这类Web页的典型特征是用一个基于ajax技术的无刷新的页面完成大量复杂的功能。此类页面包括Web IM、Web Map、Gmail等应用，统称为one-page Web应用。同时，在企业级Web开发中，一个Web页同时完成多个复杂功能的情况也越来越多。在这些复杂Web页应用中， Javascript代码是此类富客户端应用程序的核心，负责与用户的复杂交互和页面展现。One-page Web页面javascript代码规模往往非常庞大，逻辑复杂，动则千行以上，有时甚至需要一个团队来完成一个页面的开发。如何合理组织大量的javascript代码，使之具有良好的扩展性，能够适应需求的变化，使代码易于维护，是广大Web前端开发人员面临的一大挑战。

纵观Web应用程序开发的历史，Web后端开发(PHP、J2EE、ASP.NET)与Web客户端开发的发展过程有一定的相似性，曾面临类似的问题。最初，Web程序功能简单，代码较少时，所有的控制、逻辑、UI展现代码混杂在一起；随着Web发展，程序规模变大，按原有方式开发出的程序显然不具有良好的结构，不利于大规模开发和后期维护，也不利于Web开发人员工作和角色的进一步细分，代码复用性差，瓶颈开始出现。Web后端程序设计者的解决方法是进行代码分类，将控制代码与展现代码开始分离， 于是Web后端开发从所谓的Model1发展到Model2；同时，传统桌面程序设计中的MVC(模型-视图-控制器)设计模式被引入，负责程序数据与逻辑计算的部分进一步分离出来，形成了Web后端开发中的MVC开发模式。MVC设计模式贯穿了软件工程分而治之的思想，有效解决了Web后端程序设计中的代码组织和复用问题。采用同一设计模式(MVC)也使代码更容易被他人理解，保证代码可靠性；它使Web开发工作可以细分为业务逻辑开发和UI展现开发。因此，MVC也利于团队开发。那么，MVC设计思想是否也能应用在前端开发中解决相关问题呢？既然问题具有许多相似性，笔者沿着相同的解决思路来试图解决前端开发中的代码组织问题。

2.MVC设计模式

在提出本文提出的MCRV设计模式之前，有必要对其所基于的MVC设计模式进行阐述。

MVC这个概念很早之前就被人提起[1]，它代表一种设计思想。MVC是Model-View-Conroller的缩写，即模型-视图-控制器。这种开发模式将一个应用程序分为三个部分，模型(model)实现商业逻辑，提供数据；视图(view)负责向用户呈现界面和接受用户交互；控制器(controller)则负责响应用户交互请求，对用户请求进行翻译，根据不同的请求调用模型，执行商业逻辑。控制器本质上是一个调度器 (dispatcher)，通过其包含的各个方法(action)来执行具体的商业逻辑。MVC各个部件以最小的耦合性协同工作，从而使程序具有良好的可扩展性和可维护性和复用性。

MVC设计模式最开始被用于桌面程序设计，典型地用于相同的数据需要不同的用户交互界面的设计场景。在经典的MVC设计思想中，控制器负责响应用户事件，根据事件类型和参数调用模型或改变视图。每个模型对应一个或者多个视图，当模型被控制器调用而得到改变时，模型向所有向其注册过的视图发送通知，视图根据从模型的中得到的信息改变外观。这种设计模式可以用图1表示。可以看出经典MVC设计模式中Controller、Model 都可以改变视图。

图1 经典MVC

基于MVC模式的Web开发(后端)一般可以用图2表示。在这种模式下，controller负责解析用户浏览器请求的URL，根据URL自动调用controller中的不同的Action响应用户请求。Action调用model，然后将model返回的数据填充到view中，view被返回给用户浏览器。Web服务端开发中典型的采用MVC模式的框架有CakePHP、Structs、Spring等等。

图2 Server端Web开发中的MVC

相对于早期的经典MVC模式，Web开发中的MVC模式存在一些变化，因为对于一个桌面应用程序而言，可以很方便地将视图注册给模型，当模型数据发生改变时，即时通知视图页面发生改变；而对于Web应用而言，即使将多个页面注册给一个模型，当模型发生变化时，模型无法主动发送消息给Web页面（因为Web应用都是基于请求/响应模式的），只有当用户请求浏览该页面时，控制器才负责调用模型数据来更新Web页面。同时，Web开发中的MVC也比经典MVC具有更小的耦合性，因为Model不再与View发生交互，因此程序的结构更加良好，使Web前端开发和业务逻辑开发相分离变的简单。

对于具有复杂交互逻辑和丰富界面的程序来说，MVC已被实践证明是一种行之有效的设计和开发思想。采用MVC设计模式的系统具有较好的结构，较低的耦合性，代码具有很好的维护性，能够适应复杂的业务逻辑和视图展现变化。它也非常适合团队开发，使开发人员分为不同的角色，专注于自己负责部分的开发。

3.MCRV设计模式

综上所述，MVC是解决具有复杂交互界面、代码规模大的应用程序面临代码组织、复用问题的有效设计模式。基于此，本文尝试基于MVC设计思想解决前端开发中的类似问题。

然而，在前端页面开发中不能直接套用MVC设计模式。因为，前端开发中的Web页面包含了HTML、CSS、Javascript等多个种类的代码，相对Web后端来说，Web页面整体就是一个负责UI展现、用户本地交互、发送服务请求的大View，与经典MVC及Web后端开发MVC模式中的View皆有不同。因此，需要具体问题具体分析。

首先对Web页面中的HTML、CSS、Javascript等代码进一步分析，明确它们的具体功能分类。根据业界提出的Web开发标准，Web页首先被分为了内容-结构-表现-行为几个部分。内容、结构、表现是页面的静态部分，主要负责UI的展现，用户操作指令（键盘、鼠标）的接受，因此，内容、结构、表现属于视图 (View)的范畴。行为主要就是javascript代码，负责对用户操作指令的响应。在复杂ajax应用中， javascript代码的功能一般包括：响应用户指令，执行数据验证/处理、执行客户端交互逻辑，向服务器发送ajax请求，接受并处理服务器返回的数据，根据数据改变UI（向页面结构填充内容数据、变换样式等）。基于模型-视图-控制器分离的思想，Javascript代码中的数据验证/处理、本地业务逻辑计算、向服务器发请求获取数据的功能，对应模型(Model)的功能；响应(翻译)用户操作指令，根据指令执行业务逻辑处理的功能，属于控制器(Controller)的功能；而接受处理过的数据，根据数据修改页面的内容/结构/样式的功能既不属于控制器的功范畴，也不属于模型的功能范畴，这部分代码因为根据数据对View进行呈现(render)，可以命名为Renderer(渲染器或呈现器)。

根据前述分析，本文提出了MCRV设计模式，如图3所示。阐述如下：

   M(Model)：模型。完成数据验证、数据处理，执行客户端业务逻辑计算，或向服务器发起ajax请求调用服务端逻辑、接受返回的数据，将处理后的数据返回控制器。
   C(Controller)：控制器。控制器响应View上的事件，根据事件调度执行模型的业务逻辑，从业务逻辑获取返回数据，调度相应的渲染器(Render)来完成界面展现。在这个过程中控制器会有数据的传递：控制器调用模型中的逻辑时会传送Renderer搜集的数据(form表单各域的name/value、其他控制参数)，模型执行逻辑后返回作为执行结果的数据给控制器，控制器根据数据来调用渲染器(renderer)来完成界面呈现(rendering)，呈现(rendering)就是修改页面结构、内容和样式的过程。数据传递过程可以用图4表示。
   R(Renderer)：渲染器(呈现器)。渲染器被控制器调用，接受从控制器传递的数据，完成对界面的具体渲染。渲染器也负责控件(widget)的初始化，及建立Controller与具体事件的对应关系，事件发生时负责搜集View上的数据传送到Controller。
   V(View)：视图。视图是用户最终看到的整个Web界面，由结构、内容、样式（表现）等静态内容共同构成。View由Renderer进行初始化渲染和修改。

图3:MCRV开发模式

图4：数据传递过程

可以看到在MCRV开发模式中，Controller处于控制中心的位置，Model完成具体的商业逻辑计算以及向后端发起ajax请求返回数据的功能。Controller与Model、Renderer之间的交互本质上数据交互的过程，它们之间存在着一个数据流，如图4所示。因此，制定Controller、Model、Renderer之间的交互接口时，数据格式定义很重要。

4.基于MCRV设计模式的Demo

下面是一个用MCRV模式来开发的Demo页面，页面的功能是用表格展示和修改用户信息。javascript使用了jQuery库。页面界面如图5所示。页面代码在程序清单1中

图5：基于MCRV设计模式的用户管理Demo

程序清单1

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
    <meta http-equiv="content-type" content="text/html;charset=utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=7" />
        <title>MCRV 设计模式 Demo</title>
        <style type="text/css">
            /********表现*********/
            table{width:100%;border-collapse: collapse;}
            td{border: 1px solid black;padding: 2px;}
            #container {width:800px;margin:0px auto;}
            #tbUsers{margin:20px auto;}
            #tbUsers th{background-color: navy;color:white;text-align: center;vertical-align: middle;border:1px solid navy}
             #tbUsers td{text-align: center;}
            .editCaption{width:100px;text-align: right;}
            .buttonMargin{margin:0px 20px;}
            .buttonContainer{text-align: center;vertical-align: middle;height:50px}
        </style>
        <script src="./jquery-1.3.2.min.js" type="text/javascript" charset="utf-8"></script>
</head>
<body>
    <!-------结构--------->
    <div id="container">
        <table id="tbUsers">
            <thead><th>id</th><th>姓名</th><th>年龄</th><th>修改</th></thead>
            <tbody/>
        </table>
        <div style="display: none;" id="dvEditPanel">
            <form id="frmModify" name="frmModify">
                <table>
                <tr>
                    <td class="editCaption"> id: </td>
                    <td><span id="spID"></span></td>
                </tr>
                <tr>
                    <td class="editCaption"> 姓名: </td>
                    <td><input type="text" size="20" id="txtName"/></td>
                </tr>
                <tr>
                    <td class="editCaption"> 年龄: </td>
                    <td><input type="text" size="20" id="txtAge"/></td>
                </tr>
                <tr>
                    <td colspan="2"  class="buttonContainer">
                        <button id="btnSubmitModify" class="buttonMargin" type="button">提交</button>
                        <button id="btnCancelModify" class="buttonMargin" type="button">取消</button>
                    </td>
                </tr>
              </table>
            </form> 

        </div>
    </div>
    <script>
        /***************************行为********************************/ 

        var UserManagerMCR;
        $(function()
        {
            UserManagerMCR=new MCR(UserController,UserModel,UserRenderer);
        }); 

        /*
         * MCR 三元组
         */
        function MCR(Controller,Model,Renderer)
        {
            this.controller=new Controller();
            this.model=new Model();
            this.renderer=new Renderer();
            this.controller.model=this.model;
            this.controller.renderer=this.renderer;
            this.model.controller=this.controller;
            this.renderer.controller=this.controller;
            if(typeof this.model.init=="function")
            {
                this.model.init();
            }
            if(typeof this.renderer.init=="function")
            {
                this.renderer.init();
            }
            if(typeof this.controller.init=="function")
            {
                this.controller.init();
            }
        } 

        /*
         * 控制器
         */
        function UserController()
        {
           this.init=function()
            {
                this.initUserList();
            } 

            this.initUserList=function()
            {
                var list=this.model.getUserList();
                this.renderer.renderUserList(list);
            } 

            this.beginModify=function(data)
            {
                var user=this.model.getUserByID(data.id);
                this.renderer.showModifyUI(user);
            } 

            //提交修改
            this.submitModify=function(user)
            {
                var result=this.model.modifyUser(user);
                if(result.success)
                {
                    var list=this.model.getUserList();
                    this.renderer.renderUIWhenSubmitModifySuccess(list);
                }
                else
                {
                    alert(result.msg);
                }
            } 

            //取消修改
            this.cancelModify=function()
            {
                this.renderer.hideModifyUI();
            } 

        } 

        /*
         * 模型
         */
        function UserModel()
        {
            //模拟的数据，实际应用中经常从服务器获取 

           this.init=function()
           {
              this.data = [
                {id:0,name:"John",age:22},
                {id:1,name:"Tom",age:30},
                {id:2,name:"Tony",age:25}
               ];
           } 

            //获得用户数据列表
            this.getUserList=function()
            {
                //todo ,可能ajax从后端返回
                return this.data;
            } 

            //获得用户数据
            this.getUserByID=function(id)
            {
                var ix;
                $.each(this.data,function(i,item){if(item["id"]==id ) { ix=i; return false;}});
                return this.data[ix];
            } 

            //修改用户数据
            this.modifyUser=function(user)
            {
                var result={success:true,msg:"修改成功"};
                //todo,验证参数user
                //todo,修改用户数据
                $.each(this.data,function(i,item)
                {
                    if(item["id"]==user["id"])
                    {
                        item["name"]=user["name"];
                        item["age"]=user["age"]
                        return false;
                    }
                });
                return result;
            } 

        } 

        /*
         * 渲染器
         */
        function UserRenderer()
        {
            this.init=function()
            {
                 var me=this;
                 $("#btnSubmitModify").click(function()
                 {
                     var user={id:$("#spID").text(),name:$("#txtName").val(),age:$("#txtAge").val()};
                     me.controller.submitModify(user);
                 });
                 $("#btnCancelModify").click(function()
                 {
                     me.controller.cancelModify();
                 });
                 $("#tbUsers .modify").live("click",function()
                 {
                     var id=$(this).attr("uid");
                     me.controller.beginModify({"id":id});
                 });
            } 

            this.renderUserList=function(list)
            {
                var htm=[];
                for(var ix=0;ix<list.length;ix++)
                {
                    htm.push("<tr><td>" +list[ix]["id"]+"</td>" +"<td>"+list[ix]["name"]+"<td>"+list[ix]["age"]+"</td>"
                        +"<td>"+"<a class='modify' href='javascript:void(0)' uid='"+list[ix]["id"]+"'>修改</a></td>"+"</tr>");
                }
                $("#tbUsers").children("tbody").html(htm.join(""));
            } 

            this.showModifyUI=function(user)
            {
                $("#dvEditPanel").show();
                $("#spID").text(user["id"]);
                $("#txtName").val(user["name"]);
                $("#txtAge").val(user["age"]);
            } 

            this.hideModifyUI=function()
            {
                document.frmModify.reset();
                $("#dvEditPanel").hide();
            } 

            this.renderUIWhenSubmitModifySuccess=function(list)
            {
                this.hideModifyUI();
                this.renderUserList(list);
            }
        }
    </script>
</body>
</html>

5.基于MCRV模式的开发框架原型

5.1基本设计思想

框架是在一个特定的问题领域内，应用程序的部分设计与实现[2]。框架与设计模式通常是精密结合的。框架规定了应用的体系结构，使基于特定设计模式的开发能够复用公共代码；反之，框架强调设计复用，框架设计也基本上使用了设计模式，掌握了框架的设计模式可以快速掌握基于框架的应用程序开发。因此，使用MCRV设计模式进行前端开发时最好有一个与之配合的javascript框架。
基本设计考虑：

 Model、Controller、Renderer组成一个三元组MCR，一个MCR三元组中Controller对象、Model对象和Renderer对象是唯一的。

 Model、Controller、Renderer可以初始化和销毁

 Controller、Model、View在需要时可以透明地引用其他对象

 数据与逻辑分离，支持数据本地存储

 一个Web页面可以有多个MCR组，即可以有多个Controller、Model、Renderer三元组分别完成不同的控制、逻辑、展现。这为一个页面逻辑和交互非常复杂时，拆分为多个模块，由多人开发提供了支持。

5.2 基本对象及其关系

下面是一个基于上述考虑的基于MCRV设计模式的javascript框架原型（以下简称MCRV框架）。
框架的基本对象：MCR、Model、Controller、Renderer、Cache。如图6所示。

图6 基于MCRV模式的框架原型

 MCR：控制器(Controller)对象、模型对象(Model)和渲染器对象(Renderer)的复合对象。

-Dispose()方法：执行MCR销毁操作，避免javascript内存泄露；在页面unload时自动调用；这个方法自动调用Model、Controller和Renderer的dispose()方法

-model属性：包含的模型

-controller属性：包含的控制器
-renderer属性：包含的渲染器

 Model：模型对象。

-init()方法：执行模型初始化

-dispose()方法：执行对象销毁,释放资源

-cahce属性：数据的缓存。

 Controller：控制器对象

-init()方法：执行控制器初始化

-dispose()方法：执行对象销毁,释放资源

-model属性：调度的模型

-renderer属性：控制的渲染器

 Renderer：渲染器对象

-init()方法：执行渲染器初始化

-dispose()方法：执行对象销毁，释放资源

-controller属性：对controller的引用

 Cache：基于key-value的缓存对象

-get()方法：基于键值获取缓存数据

-set()方法：设置缓存数据

-remove()方法：删除对应某个键值的缓存

-size()：缓存数量

5.3 MCRV框架与其他web其他部分的关系

基于MCRV模式的开发框架与Web页面开发其他组成部分的关系可以用图7表示。MCRV框架搭建起了js应用程序整体的结构，提供了应用程序上下文环境。MCRV框架可以与js组件库、css基础样式库和js业务逻辑组件一起作为应用程序构建的基础，并且它们之间没有依赖关系。尽管应用程序可以在js基础库（如jQuery）上开发，但是MCRV框架不依赖这些库。

图7 基于MCRV模式的开发框架与其他Web页其他部分的关系

6.结论

实践表明，MCRV设计模式能够有效解决复杂ajax开发中面临的问题，可以使Web页面代码结构良好，降低javascript代码的耦合性，提高复用性、适应性和灵活性，使Web页更加易于维护和重构。

参考文献

[1]. Trygve Reenskaug Taskon.Working with objects in the user interfaces.

[2]. J. Van Gurp, J. Bosch.Design, Implementation and Evolution of Object Oriented Frameworks Concepts and Guidelines.pdf.

启程

我们乘坐12号下午4点的国航飞机出发，经过11小时到达了旧金山国际机场，由于时差的关系，到了旧金山后的当地时间是12号中午12点，感觉像穿越了。

下飞机后我们租了2辆车，在美国租车是最经济方便的交通工具，因为地广人稀，除了大城市其它地方都很少见到公交和出租车，导航仪很精确，很顺利就从机场开到了宾馆。

参观Facebook总部

13号我们参观了公司在Cupertino的办公室，然后在HR的带领下驱车前往Facebook总部进行参观，Facebook内部不大，只有2层办公室，里面的场景和电影social network中见到的一样，不像想象中的吵，但也不安静，很多人都戴着耳麦，由于签署了保密协议不能拍照片，感兴趣的同学可以观看Facebook官方的MTV Diary of Facebook，幸运的是我们在办公室里还见到了Mark。

然后我们在一个会议室里和2位Facebook工程师简单进行了交流，对Facebook最大的感受就是其内部的小巧和高效，像一个小公司一样在运作，每个工程师都可以自由修改任何Facebook的代码（当然，会有code review和自动化测试才能上线），Facebook有健全的小流量测试机制来不断改进产品，任何人都能提需求，然后通过对比测试来决定某个功能是否大规模部署，他们没有专门的QA，而是由工程师自己来保证质量。

保持小巧是Facebook高效率运作的一个重要原因，目前Facebook的工程师只有500人左右，而且他们不想增长太快。在这次Velocity大会上Jonathan的演讲也提到了Facebook的内部的工程师文化：small and hungry，在对php进行优化时他们最终选择hiphop这个高风险但高收益的方案，感觉很少有大公司会这么激进。

之前网上有篇文章How Facebook Ships Code谈到了Facebook内部运作的很多细节，感兴趣的同学可以阅读，与传统的企业相比确实有很多值得借鉴的地方。

6月14号的workshop

由于每个分会场的人都太多了（超过400），第一天的workshop基本上相当于演讲，之前还以为主要是动手实验。

接下来我会列举出每个session相关的信息，大家可以点击session标题浏览详细的信息，其中大部分session都有slide可以下载，有些还有视频（youtube），而对于还没有视频的session请耐心等待一段时间。

Performance Tools

这个session主要介绍了4个性能优化相关的工具：WebPagetest、Mobitest、ShowSlow、dynatrace。

首先介绍的是WebPagetest，这是google员工Patrick Meenan全职开发的性能监测工具，它可以通过截图来直观地看到页面加载的过程，并能进行视频对比，方便演示性能优化结果，WebPagetest是目前功能最全面的开源监测工具，还可以部署到本地机器，方便进行内部的性能测试。

Mobitest是专门用来测试iOS和android页面性能的在线服务，可以在线免费使用，但由于移动设备的局限性（性能、相关工具），能监测到的信息要比桌面上的少。它的实现原理是在这些移动设备上运行一个自己开发的app，监听服务器的指令然后调用内嵌的webkit来监测页面性能。

ShowSlow是一个聚合YSlow、Page Speed、dynaTrace测试结果的平台，方便浏览，并能查看历史数据，它的实现方法是通过收集beacons结果。

dynatrace AJAX就不用多介绍了，它目前最强大的页面性能监测工具，可以详细列出页面渲染中详细的信息，甚至是每个函数的执行时间。

Analyzing the Performance of Mobile Web

Ariya的这个演讲是这次会议最好的演讲之一，因为Ariya是WebKit的reviewer之一，他对WebKit有深入的研究，提供了不少移动设备如何进行性能优化的思路，以下是我总结的要点：

• 监测移动设备性能的方法
  • 源码注入方式，在相关部分加上日志，可以得到最详细的数据，但需要重新编译
  • 通过代理的方式，类似Fiddle 2，不过有局限
  • 通过高速摄像头，可以方便得到视觉效果，而且不影响运行的性能，但不能得到更多的数据，且不好进行分析
• PhantomJS
  • 这是一个基于WebKit的命令行工具，可以在JS中调用WebKit引擎，方便进行自动化测试
• 通过代码注入方式来监测性能
  • 可以得到页面各元素渲染的顺序
  • 可以得到细致的元素速度数据
  • JS引擎GC的情况
  • 他采用的方法是修改android的代码，然后重新编译，在绘图部分打日志
• android-tools
  • android的Web类应用开发和调试工具，包括eventrecoder和remotejs
  • remotejs可以实用console.log来获取页面中的数据，执行js等，解决了如何方便调试的问题
  • eventrecoder可以用来进行android上web的单元测试
• hammerjs
  • 一个JS的shell，基于v8实现，类似nodejs，不过功能要简单很多
  • 其中有一个模块Reflect可以用来分析js的语法，它的实现居然是从JavaScriptCore中将解析部分剥离出来，生成的结果类似SpiderMonkey的parser，这个工具可以用来简化js相关分析工具的开发。

Ariya还提供了一些性能优化和需要注意的事项，如避免创建对象等，具体请参考其slide，建议大家等这个视频出来后都看一下。

下面是其中的一页，整个slide做得相当漂亮

Mobile Web & HTML5 Performance Optimization

整体来看这个session没有什么亮点，对于mobile web开发不太了解的同学可以看看，系统了解一下，演讲者写过很多书，比较善于整理和总结，但缺乏新意。

6月15号的会议

15号是velocity第一天的正式会议，sessions很多，整体时间也比14号长。

JavaScript & Metaperformance

果然到处都能见到Douglas，这次除了介绍js语言特点以外还不忘鄙视了一下java，感兴趣的同学可以看看ppt。

Douglas说现在的JS性能测试都是骗人的，除了JSMeter看上去还行。

接下来是大家常听到的：DOM是瓶颈，大部分时间花在layout、painting等工作上，不要过早优化，避免导致代码不易维护。。。

然后他说JS中还是有优秀部分的，顺带推广自己的书JavaScript: The Good Parts。

最后忽悠大家用JSLint来作为性能监测工具，这。。。

Testing and Monitoring Mobile Apps

主要是Keynote产品的广告，不过做得很不错，介绍了Mobile Device Perspective 5，它是一个非常强大的手机测试工具，可以远程操作真实的iphone、android手机，还可以运行自动化脚本，监测应用性能等，是移动设备开发和性能优化的利器。

但实现原理不清楚，怀疑是在越狱的手机上运行后台进程，大家可以通过看视频了解其功能，这是我15号上午印象最深的一个session，欢迎了解内幕的同学指教。

Real-Time Real-Fast

主要谈使用WebSocket来减少overhead，可以用于实时性要求高的场景，然后推广了一下dojo中的socket API，它可以简化WebSocket的开发，并自动fallback到传统的long-polling方式，其它没听到什么特别的。

Performance Measurement and Case Studies at MSN

MSN的工程师分享了在性能优化方面的经验和内部数据，我这边记的一些要点：

• 之前太过于关注下载时间等网络数据，缺乏对实际展现性能的关注
• 应该更多关注渲染及展现时间，并提议浏览器增加这些监测API
• js越来越大了，要将js放底部或延迟加载及执行
• 延迟广告的加载，看上去他们的广告长宽是固定的，所以延迟是可行的
• 使用Data URL来显示缩率图，减少请求数

建议简单看一下这个slide，里面有一些性能优化对比测试的数据。

Improving Performance by Changing the Rules – From Fast to SPDY

主要介绍了SPDY对http的优化对比，在3G网络下性能提升效果显著，看slide就好了，没太多可听的，虽然Google的ssl请求都支持SPDY了，但其它网站及少有支持的。

Understanding Mobile Web Browser Performance

主要内容是介绍了手机中的网络情况，手机为了节能，网络不会一直开启，所以初次打开时会有启动网络的时间，而且3G网络延迟还是很高，也许4G会好点。

在android中只有4个线程来处理http请求，所以android中浏览器的并发不会超过4个。

android中的浏览器默认打开了pipelining，是极少数默认开启这个技术的浏览器。

10 Tricks for Mobile Performance

介绍了针对移动设备进行性能优化的建议，具体内容建议看看slide就好了。

Know Your Engines: How to Make Your JavaScript Fast

重点推荐一下David的这个session，David是Mozilla的JS引擎工程师，之前在他的blog上学习到了很多JS引擎优化的细节，这次又有不少收获，建议对JS引擎实现不太了解的同学抽空听听这个session，可以学到很多知识。

David首先讲解了JS引擎中的JIT和GC实现原理，然后介绍如何根据这些原理来优化JS代码，如避免动态改变对象的类型来优化JIT的执行、减小使用全局变量来减小GC、避免使用稀疏的数组等。

Take it all off! Lossy Image Optimization

主要针对如何优化图片这一主题，详细介绍了如何优化图片的大小，包括png、jpeg，有损、无损压缩等细节。通过一定程度的有损压缩，在性能和效果上进行权衡。

从目前HTTP Archive的数据来看，图片是占带宽最多的部分（60%左右），对其进行优化可以明显减少带宽消耗。

WebPagetest Update

WebPagetest的作者Patrick详细介绍了WebPagetest这一年来的改进，包括：

• 支持dynaTrace
• Web Page Replay
• 对外API
• 提供WPT Monitor来监控页面性能变化的情况

建议关注这个性能优化工具。

6月16号的会议

Holistic Performance

John介绍了jQuery中如何进行性能优化的，一些注意的点等：

• 需要进行全局考虑，运行快的代码有可能耗cpu和内存
• 用JS字典作为例子来解释性能优化需要考虑很多方面，包括文件大小、cpu、内存等，之前John在他的blog上讨论过
• jQuery性能优化的准则：
  • 通过JSPerf来测试优化效果，JSPerf基于Benchmark.js，是一个很优秀的JS性能测试工具，它通过很多方法来保证测试结果的准确性
  • 考虑全局优化，细节优化意义不大，纯js的性能问题很少见，基本上都是DOM性能问题
  • 保持简洁的代码，避免为了性能而减低可读性
  • 保证IE的性能，即便IE是最慢的浏览器，但由于市场占用率高，IE的性能是最重要的

Making the Web Instant

介绍了Chrome中的prerender，宣传视频很唬人，将原先需要等待6秒的页面降到了0秒，看来要是大家都用Chrome，咱们也没必要做性能优化了。

浏览器专栏

浏览器专栏和去年在北京的velocity类似，主要介绍浏览器的一些最新的进展，Chrome、Firefox、IE平时大家也都比较了解，所以没太多特别的地方。

不过今年Opera首次出现，介绍了Opera的产品线，Opera在移动领域有两个版本，mini和mobile，mobile是全功能的，而mini的渲染是由服务端完成的，原来Opera还有一个模拟器，可以用它来在桌面测试Opear mobile的展现效果。

HTML5, Flash and the Battle for Faster Cat Videos

来自YouTube的工程师介绍了YouTube中视频播放器的一些经验，并对HTML5中的video标签和Flash进行了对比，HTML5最大的优势是能和页面中的其它元素更好地结合，而Flash目前在性能上要比HTML5好，尤其是视频加载的速度。

最后建议主要使用Flash，而专门针对iOS用户提供HTML5版本，因为iOS对YouTube API流量的贡献不小。

The Impact of Ads on Performance and Improving Perceived Performance

这个session我并没有听，不过从发出来的ppt看，内容还是不错的，介绍了Yahoo mail中如何改进广告加载来提高页面性能，有很多细节的技术方案。

参观Google总部

17号我们前往位于Mountain View的Google总部进行了参观，正如传闻所说的，Google总部很大，里面人很多。

看到了传说中的恐龙骨架、飞船、大Nexus One、全景Google map、沙滩排球场，比起facebook工位要宽敞不少，还有很多4人一间的房间，里面很安静，传说中空气净化开得很足也是真的，办公室里面空气质量很不错，关于Google总部的情况大家可以搜索相关的资料，网上说的基本上靠谱。

Google总部里有很多餐厅，里面有各种风格的食物，还有中国、印度等不同地区的口味，比Facebook要大得多。

这里感谢一下Tim在百忙中抽空带我们到处参观。

整体感受

这里零碎写下一些自己一些参会的感受：

• 和国内相比还是更容易遇到牛人，比如Ariya和David的两个session是我觉得收获最大的，但在国内很难听到这样深入的演讲
• 最头疼的问题是时差，上午11点就相当于北京夜里2点，影响了开会的效率
• 今年性能优化主题已经逐渐转向了自动化测试和持续集成，通过自动化的方法来保证性能
• 标准化也是一个很大趋势，beacons和HAR这两个标准都逐渐被大家接受
• 数据分析对性能优化来说至关重要，Facebook在这方面做得很专业，从他们招聘Web Optimization工程师的职位要求也能看得出来

最后，除了开会，我们还抽空参观了漂亮的斯坦福大学：

最后去参观了宏伟的金门大桥，硅谷和旧金山的气候差距很大，忽然就变成阴云密布了：

如果下载后发现后缀是php请改成pdf。

第一节课相关课件：

0.授课计划和项目要求.pdf

1.前端的美好时代.pdf

1.WEB前端技术程序员编程能力成长之路.pdf

课堂作业：

第二节课相关课件：

2.样式之美-Web前端课程体系之CSS.pdf

2.HTML5 – Web开发步入新阶段.pdf

第三节课相关课件

3.JS－行为控制语言+js架构思想.pdf

3.tangram设计思想.pdf

第四节课相关课件

4.百度地图API

4.百度web安全2.0

What’s API?

API的全称是application programming interface。

而很多时候，程序开发者仅仅把函数、类的接口做为API的一部分，而忽略了其他重要的编程接口。

事实上，在前端Javscript编程中常见的API包括：

• 函数、类接口，包括参数，返回值，函数对外部对象（常常是DOM）的具体操作等
• 网络接口协议，如和后端交互的JSON、XML数据格式，或者script回调中的函数名
• 样式以及HTML接口
• 外部依赖（对浏览器具体特性的依赖）
• 一些无意泄露的内部实现

越往后的API，越隐晦，越不容易受到重视，但是一旦这些API发生变化，可能会导致调用方出现不符合预期甚至程序直接报错的情况。

Why API cannot be changed?

API是程序协同开发的重要保证，API的用户希望API的提供方提供的是一段功能明确、接口明了的程序。更重要的是，用户更期望在程序升级以后，他们能够“不经思考”地升级这些第三方代码。

一旦上述提到的5个API中的任何一个发生变化，可能会给他们带来巨大的代价，用户需要排查所有调用的代码，需要更改一些协议，需要调整所有与之相关的部分，这些工作对他们来说都是额外的，在预期之外的。如果辛辛苦苦完成这些以后，还在测试过程中发现了相关的bug，那对用户的打击就更大了。

如果API经常发生变化，用户就会失去对这段程序的信任，他们会更倾向自己获得源代码以后，按照自己的需求进行修改，自行维护一个内部的API比调用一个不断发生变化的外部API要容易接受的多，虽然这样做和我们协同开发、模块化开发的初衷是完全相悖的。

最后，我们为什么要修改API呢？为了API看起来更加漂亮？为了提供更多有趣的功能？还是仅仅我们觉得到了改变了时候了？对于用户来说，他们更愿意使用一个稳定但是看起来不那么时髦的API，而不是使用一个很时髦，但是会经常变动的API。在这个问题上，项目开发者是实用派。但这并不意味着我们不再改进API了，在后面，我会具体介绍如何能让API保持稳定的同时，让API持续改进。

Quality of API

在正式说兼容性之前，首先要明确一下，什么是好的API，因为导致API的不兼容的根源总是来自一个想法：“期望通过这次改变把API变得更好”。

容易理解
如果一个API不能让大多数使用者快速学会，这一定不是一个好的API。 比如iOS的滑动解锁，老人和小孩都能都能一次解锁，而Nokia的经典两键解锁，你懂的。

一致性
一致性能大大降低用户的学习和使用成本，用户过去的努力学习，能持续的收效。

容易查找和学习
API必须要有文档，并且介绍清晰，提供尽可能多的示例和可copy－paste的代码，降低用户的使用门槛。

提供简单的方案
API要能解决复杂的问题，提供很多可配置项，但是对于那些最常见的case，如果有一个简单的方案供给用户使用，这样能大大提高API的可用性

保护用户在API上的已有工作
用户过去在调用API、基于API开发所做的工作，这样才能给用户带来价值的同时，不破坏他们过去的劳动成果。

如何保证API的兼容

采用良好的设计思路

在设计过程中，如果能按照下面的方式来进行设计，会让这个API生命更长久

• 面向用例的设计，收集用户建议，把自己模拟成用户，保证API设计的易用和合理
• 保证后续的需求可以通过扩展的形式完成
• 第一版做尽量少的内容，由于新需求可以通过扩展的形式完成，因此尽量少做事情是抑制API设计错误的一个有效方案
• 对外提供清晰的API和文档规范，避免用户错误的使用API，尤其是避免API（见第一节）靠后级别的API被用户知晓与误用

除此之外，下面还列出了一些具体的设计方法：

• 方法优于属性
• 工厂方法优于构造函数
• 避免过多继承
• 避免由于优化或者复用代码影响API
• 面向接口编程
• 扩展参数应当是便利的
• 对组件进行合理定位，确定暴露多少接口
• 提供扩展点

有效的API评审

API设计完成以后，需要经过周密的设计评审，评审的重点如下：

• 用例驱动，评审前必须提供完善的使用用例，确保用例的合理性和完备性。
• 一致性，是否与系统中其他模块的接口风格一致，是否与对称接口的设计一致。
• 简单明了，API应该简单好理解，容易学习和使用的API才不容易被误用，给我们带来更多的麻烦。
• API尽可能少，如果一个API可以暴露也可以不暴露，那么就不要暴露他，等到用户真正有需求的时候再将它成为一个公开接口也不迟。
• 支持持续改进，API是否能够方便地通过扩展的方式增加功能和优化。

把握API的生命周期

每一个API都是有生命周期的，我们需要让API的生命周期更长，并且在API的生命周期结束时能让其平滑的消亡。

• 告诉用户我们是如何设计的，避免误用，提供指导，错误的使用往往是缩短API寿命的一大杀手
• 提供试用期，API不可能一开始就是稳定，经过试用的API才能有更强的生命力
• 为API分级：内部使用；二次开发使用；开发或试用中；稳定；弃用API。避免API被滥用的同时，我们可以通过调整API的级别，来扩大其影响力，也能更优雅的结束一个API的生命周期。

保持API的逐步改善

过去我们总希望能将现有的“不合理”的设计完全推翻，然后按照现在“美好”的思路，重新设计这个API，但是在一段时间以后，又会碰到一样的状况，需要再推翻一次。 如果我们没有有效的逐步改善的办法，依靠推翻现有设计，重新设计API只能让我们回到起点，然后重现之前的过程。 要有一套行之有效的持续改善的办法来在API兼容的同时，改善API使之更好。

提高API的可测试性

API需要是可测试的，测试不应依赖实现，测试充分的API，尤其是经过了严格的“兼容性整合测试”（见下文）的API，更能保证在升级的过程中不出现兼容性问题。

兼容性整合测试，是指一组测试用例集合，这组测试用例会站在使用者的立场上使用API。在API升级以后，再检测这组测试用例是否能完全符合预期的通过测试，尽可能的发现兼容性问题。

避免极端的意见

在设计API的时候，一定要避免任何极端的意见，尤其是以下几点：

• 必须漂亮（API一定要漂亮吗？前文已经说过了）
• API必须被正确地使用（用户很难理解如何正确的使用API，API的设计者要充分考虑API被误用的情况：如果一个API可能会被误用，那么它一定会被误用）
• 必须简单（我们总会面临复杂的需求，能两者兼顾的API是更好的API）
• 必须高性能（性能可以通过其他手段优化，不应该影响API的设计）
• 必须绝对兼容（尽管本文一直提到如何保证兼容，但是我们仍然要意识到，一些极少情况下会遇到的不兼容是可以容忍的）

一些具体的实施方案

在一个API不可避免要消亡或者改变的时候，我们应该接受并且面对这个事实，下面列举了几种保证兼容性的前提下，对API进行调整的办法：

• 将API标记为弃用，重新建立一个新的API。如果一个API不可避免要被消亡，这是唯一的办法。
• 为其添加额外的参数或者参数选项来实现功能添加
• 将现有API拆成两部分，提供一个精简的核心API，过去的API通过封装核心API上实现。这通常用于解决用户需要一个代码精简的版本时。
• 在现有的API基础上进行封装，提供一个功能更丰富的包或者类

小结

设计一个保持兼容的API是很困难的。在这之前，作者需要理解什么是API，以及如何评估API的质量以后，通过良好的设计思路以及改进方法，来保证API的向后兼容。

其他

事实上，Tangram base库自从1.3.4版本以后，就已经做到了API的向后兼容，如果对Tangram感兴趣，可以前往Tangram网站查阅。

如果你对Javascript 的API兼容有什么自己的见解，欢迎留言讨论。

课程从web前端发展趋势，到CSS样式表，JS语言等前端专业领域，再到前沿的HTML5&CSS3，地图API，web安全，涵盖了几乎所有主流 web前端领域的知识体系。这是两所高校首次开设web前端领域课程。包括百度首席产品设计师孙云丰以及web前端研发部的高级工程师们在繁忙的工作压力 下还努力抽出时间编写教案和准备课程。当然，还有出卖色相。。。用海盗装吸引了众多学生的眼球！

在6月14日下午在中科院成功的进行了web前端前沿技术的第一堂课！吸引了250多名科苑学子报名参加。

（孙云丰在讲解搜索产品的发展）

（百度web前端研发部高级工程师李学健在讲解web前端发展过程）

（百度web前端研发部前端架构师黄方荣在讲解web前端技术总览）

根据在开发流程中出现的顺序，对每个工具简要介绍如下：

- firebug : 几乎所有写html/css/js代码的人都熟悉的工具，tangram开发调试中用到。

官方站点 : http://getfirebug.com/

- closure linter    (gjslint)  代码检查工具。Google开发的js代码检查工具，它能够检查代码风格，语法错误，还能够自动优化代码，功能十分强大。我们在开发完Tangram的代码后用它来检测代码风格以及语法错误，来保持代码风格统一和提高代码质量。

官方站点 : http://code.google.com/closure/utilities/docs/linter_howto.html

-  qunit  jquery 团队开发的js单元测试框架，和jquery一样简单好用。我们开发时采用该js框架写测试用例。而我们的测试团队将其集成到测试平台内，然后在远程虚拟机上搭建了各种操作系统和浏览器的环境。该测试平台每天都会在各种浏览器下运行当天提交的所有代码的测试用例，并通过邮件自动发送测试报告。

官方站点 : http://docs.jquery.com/QUnit

- Rietveld Code Review Tool  python 之父写的code review工具，通过它能很方便的进行多人code review 。Tangram在内部开发的每行代码都必须经过这个code review平台 review通过后才能提交到github。

官方站点 : http://code.google.com/p/rietveld/

-  jsdoc-toolkit   js版的javadoc，用于从源代码的注释生成文档。目前整个tangram.baidu.com的文档都是使用jsdoc-toolkit生成的。

官方站点 : http://code.google.com/p/jsdoc-toolkit/

- git git是linux之父 Linus Torvalds 开发的用于管理linux源代码的代码版本管理工具， 它具有分布式等特点，既能在单机上管理你写给自己用的小项目，也非常适合开发人员众多的大型项目。它方便的贡献代码机制更是为开源项目量身定制。tangram项目使用git进行版本管理，同时源代码也托管在github.com上。

官方站点 : http://git-scm.com/

- ant    apache基金会旗下项目，用来build代码。tangram每次发布新版本时提供下载的各种源代码都是通过该工具生成。在tangram的release目录下就可以看到对于该工具的配置。

官方站点 : http://ant.apache.org/

- yui compressor js/css压缩工具，用于压缩js代码，减少下载消耗的带宽。tangram codesearch工具 以及发布的版本中包含的压缩代码都是该工具完成的。

官方站点 : http://developer.yahoo.com/yui/compressor/

当然还有另一个优秀的代码压缩工具 google closure compiler ,代码压缩率比yui 压缩工具要高

官方站点 : http://code.google.com/closure/compiler/

曼昆在《经济学原理》里面说，决定一个国家实力与人民生活水平高低的因素是这个国家的生产力水平。同样也可以说，决定一个软件公司实力与程序员工资高低的因素是该公司的代码生产力水平。tangram使用的这些开源工具大大的提高了我们的开发效率和开发水平，我们对它们的创造者们充满崇敬和感激。同样，让tangram成为对大家有用的开源工具，也是我们tangram开发团队的目标。

介绍移动应用程序

移动程序界面中有一个重要的概念：屏幕，如下图

在MP3电台这个程序中，选台界面和播放界面就是两个“屏幕”，在PC端，这些操作是可以在一起进行的，可是由于移动设备屏幕大小的原因，无法塞在一个界面里。所以我们在选完台之后，整个屏幕都将转换为电台播放界面。

Flex Hero中的View

在Flex “Hero”里，“屏幕”的概念叫做View。hero中关于移动平台的核心类如下：

其中，MobileApplication相当于桌面版本的Application，是整个程序的容器。ViewNavigator管理各个View的显示与切换，也包含顶部控制栏ActionBar。

ViewNavigator处理视图切换的方法：

ViewNavigator.pushView方法用于转换到新的视图，例如，当用户在频道列表页面选择了一个频道时，我们可以执行

这样的话，就切换到了RadioPlay这个视图。

这时，如果用户按下了android上的后退按钮，则Flex框架会自动执行navigator.popView操作，这样会回到上一个视图。当然，我们也可以捕获这个键盘事件，然后执行自定义代码。

数据驱动的视图

视图切换时，Flex默认会把上一个视图的UI销毁（可以通过设置destructionPolicy=”none”来避免销毁），这样一来，我们回退到上一个视图的时候，就会丢失之前的UI状态，比如说频道列表的选中状态

View包含一个属性data，当开发者使用pushView方法时的第二个参数data将被赋值到这个属性中。而每次用户按下机身上的返回按钮，Flex框架执行popView方法自动恢复历史记录时，也会把上一次的data属性重新放到View的构造方法中。可以看出，如果我们需要在界面切换时保存当前视图的所有状态，相关代码如下：

这样，我们在离开频道列表页的时候，就会把当前列表的选中状态记录下来，在重新显示这个View的时候，我们可以再恢复回来：

优化技巧与注意事项

Android上的AIR不会自动退出，也就是说，当用户按下home键或者后退到主屏幕时，AIR程序依然在运行。对于电台这样一个应用，后台运行是合乎情理的，但是如果想像传统程序一样，后退即退出的话，则需要额外做一些工作了：

AIR在一些设备上的动画运行效率比较低，我们可以给运动的元件设置cacheAsBitmapMatrix=true，将此元件交给GPU硬件渲染。这个属性和桌面版本的cacheAsBitmap的用法几乎完全一样，对于需要平移、缩放的显示对象，设置这个属性可以大大加快动画效率。

最后，MP3电台应用的源文件可以在这里下载。

我的快乐

我的理想

我的来头　　

我的过程

……

“我”来自百度用户体验部。

“我”用生命和激情，成就梦想。

“我”在百度这个舞台，绽放华丽。

时间紧，任务重，用户体验部的同学们对“我”有很高的期望。 启动后，同学们就各司其责，投入到了紧张的筹办阶段，会议室、影棚、排练厅，大家热血澎湃，挥洒汗水，尽可能挤时间做到最好。整体规划、头脑风暴、拍摄素材、宣传设计、制作视频、购买道具，节目预审、录音排练、会场支撑……虽然辛苦，却很有劲头，很投入。

讨论创意大家积极的给出意见，安排剧情演员们热情地讨论，服装道具的准备，灯光特殊要求的配合，旁白音乐的剪辑……同学们各司其职、尽心尽力。每一项都是“我”不可或缺的一个部分，就像日常的工作一样，少了任何一个环节，“我”都无法顺利的进行下去。

在准备过程中，年会组织者也给予了“我”许多方面的支持和帮助，让“我”能更加出彩！

“我”渴望用绚丽的色彩给大家带来最强烈的视觉冲击。

“我”渴望用动感的舞蹈展示年轻和活力。

“我”渴望用独特的视角给大家新奇的感官体验。

1月22日， “我”终于在百度年会的舞台盛装亮相！有珍惜、有感动、更有鼓舞，这种精神会一直感染着“我”！再努力，“我”可以做得更好。期望来年的年会能更加精彩！