AngularJS应用开发思维之1：声明式界面
这篇博客之前承接上一篇：http://www.cnblogs.com/xuema/p/4335180.html
重写示例：模板、指令和视图
AngularJS最显著的特点是用静态的HTML文档，就可以生成具有动态行为的页面。
还是前面的小时钟示例，我们使用AngularJS模板来重写，示例已经嵌入→_→：
示例地址：http://www.hubwiz.com/course/54f3ba65e564e50cfccbad4b/
HTML文件看起来像普通的HTML，只是其中多了一些特别的标记 （比如：ng-app,ez-clock等等）。在Angular中，这个HTML文件被称为模板。
ng-app这样的标记我们称之为指令。模板通过指令指示AngularJS进行必要的操作。 比如：ng-app指令用来通知AngularJS自动引导应用；ez-clock 指令用来通知AngularJS生成指定的时钟组件。
当AngularJS启动应用时，它会通过一个编译器解析处理这个模板文件，生成的结果就是： 视图：
我们定义了两个部件：模板（包含指令的HTML文件）和指令实现 （JavaScript文件），AngularJS将这两部分拼装起来，生成了最终的视图。
有点理解框架的含义了吗？
使用指令封装JavaScript代码
我们在模板中使用了一个自定义的标签ez-clock，而它变成了一个会动的时钟， 这期间发生了什么事情?
肯定不是浏览器干的，它不认识ez-clock是什么东西。
angular.min.js引入了基本的angularJS库，它会在浏览器载入HTML文档并且 建立好DOM树后，执行以下操作：
- 找到有ng-app属性的DOM节点
- 以这个节点为根节点，搜索自定义指令，发现ez-clock
- 调用ez-clock指令的实现函数（指令类工厂）进行展开
根据我们的定义，ez-clock的展开操作如下：
- 使用一个div元素替换这个自定义标签
- 创建一个定时器，在定时器触发时刷新div元素的innerText
ez-clock这样的非HTML标准标签，在AngularJS中之所以称为指令/directive， 就是指看到它时，基础框架需要对其进行解释，以便展开成浏览器可以理解 的东西（HTML元素和脚本），而这个解释的过程被称为：编译。
可见，AngularJS框架要求将HTML文档和JavaScript代码分割的更清晰，通常混杂在 HTML文档中的JavaScript代码，需要以指令的形式进行封装，而模板、指令 实现代码这两个部件，则由基础框架负责拼装运行。
将指令看做API
将DOM操作封装成指令，更容易进行分工与代码复用。
由于AngularJS更清晰地界定了一个WEB应用的组成部分，这样，在一个团队中，可以有人负责 实现指令，有人负责开发模板，各自干擅长的事情，效率更高，成本更低。
当然，从编写界面HTML模板的角度看，诸如ez-clock之类的指令比div更具有语义性， 使模板更容易维护，使指令的实现升级不影响模板，这也是不小的好处了。
与我们所熟悉的对象、函数这类接口完全不同，指令算是一种新型的API，它提供了在 静态化的HTML文件中，植入动态行为的能力：
定义自己的指令
AngularJS内置的指令不能完全满足实际开发的需要，通常我们需要定义自己的指令：
- 增强标准DOM元素的行为
比如，希望一个DOM元素是可拖拽的，那么可以这样写：
- <p ez-draggable="true">...</p>
通过ez-draggable指令，我们赋予DOM元素可拖拽的能力。
- 自定义组件
比如，我希望一个图片裁剪功能，那么可以这样写：
- <ez-photoshop src="a.jpg"></ez-photoshop>
通过ez-photoshop指令，我们定义了一个包含交互行为的web组件。
- 封装其他组件库
这不是AngularJS鼓励的方向，但是确实有强劲的需求。
起点：声明化
基于前面的示例，我们容易感受到使用AngularJS进行应用开发的一个重要的思维模式： 从构造声明式界面入手。
事实上，我猜测这也是Misko开发AngularJS最初的动机。稍早一些的Flex、WPF和Firefox 的XUL，或多或少给了Misko启发。
在使用AngularJS进行前端开发时，始终应该从构造声明式界面模板开始，如果现成的指令不够 用，那么就定义自己的指令、实现自己的指令。这是一个迭代的过程。
记住，指令是新型的API，用界面的声明化作为需求，来指导我们的代码封装。