ExtJS模型与jsonapi规范的关联

ExtJS 史上第一次进行了重整新的类系统的大重构。新的架构以ExtJS 4.X所编写的每一个类作为后盾，因此在你编写代码以前理解它是非常重要的。

这个手册主要面向任何想在ExtJS 4.x中新建或者扩展类的开发人员。它分成四个部分：

Ø 部分一：“综观”解释了稳定的类系统的需求

Ø 部分二：“命名规则”讨论给类、方法、属性、变量和文件命名的最佳实践

Ø 部分三：“动手实践”提供详细的一步步编码的例子

Ø 部分四：“错误处理&调试”提供如何处理一场的小建议和小计谋

一 综观

ExtJS 4 靠超过300 多个类驱动。我们拥有一个超过20万来自世界各地，具备各种编程背景的开发人员组成的巨大社区。在一个框架的范围内，我们面对提供一个通用的编码结构的那些大挑战：

Ø 简单易上手

Ø 开发快速、调试简单、部署无忧

Ø 结构良好，可扩展可维护

JavaScript 是 classless 的面向原型的语言。天性使然，灵活是这个语言最强大的特性。使用不同的方式，不同的编码形式和技术，都可以让工作有效。然而就是那个特性，带来了不可预知的代价。没有一个统一的形式，JavaScript代码可能很难去理解、维护和重用。

从另一方面来看，基于类的编程仍然是面向对象编程领域最受欢迎的模式。基于类的语言常常需要强类型，提供封装和标准的编码规范。一般而言要让开发人员遵守一大堆规则，而编码就会变得一直可预知、可扩展和规规矩矩。然而，他们不会有在JavaScript这样的语言中发现的同样的动态能力。

每种方法都有其利弊，但是我们是否可以利用两者好处的同时避免他们的坏处呢？答案是肯定的，我们在ExtJS 4中实现了这个解决方案。

二 命名规范

至始至终为你编码的类、命名空间和文件名使用一致的命名规则有助于保持你代码的组织性、结构性和可读性。

1）类

类名应该只包含字母和数字字符。数字在大多数情况下是不鼓励使用的，除非他们属于一种技术手段。不要使用下划线，连字符或者其它任何非字母非数字的字符。举个例子：

Ø MyCompany.useful_util.Debug_Toolbar 不鼓励这样命名

Ø MyCompany.util.Base64 是可以被接受的

类名应该被组成成为包，在包中合适恰当的使用对象属性点记号（.）分出命名空间。至少，应该只有唯一的顶层命名空间后面跟类名。举个例子：

MyCompany.data.CoolProxy

MyCompany.Application

顶层命名空间和真实类的命名应该采用Camel形式（单词的首字母都大写），其它所有事物都应该是小写的。举个例子：

MyCompany.form.action.AutoLoad

不是Sencha发行的类永远不应该使用Ext作为顶层命名空间的名字。

首字母缩略词也应该遵守上面列出的Camel形似命名规则。示例如下：

Ext.data.JsonProxy 而不是Ext.data.JSONProxy

MyCompany.util.HtmlParser 而不是 MyCompary.parser.HTMLParser

MyCompany.server.Http 而不是MyCompany.server.HTTP

2）源代码

类地址的名字应该直接指向文件被存储的路径。基于此，每个文件中只能有一个类，示例如下：

Ext.util.Observable 被存储在路径 /to/src/Ext/util/Observable.js 中

Ext.form.action.Submit 被存储在路径 /to/src/Ext/form/action/Submit.js中

MyCompany.chart.axis.Numeric 被存储在路径 /to/src/MyCompany/chart/axis/Numeric.js中

Path/to/src 是你的应用程序类所在的路径。所有的类都应该在这个公共的根下面，并且为了获得最好的开发、维护和部署体验，适当的赋予命名空间。

2）方法和变量