Javascript前端UI框架工具包用户指南中Kit js的对话框组件

Kit是UI库，不打算让大家学习我Kit的核心，背我的API。这种跟风的学习方法一点意义都没有。今天jQuery火爆，大家都在学jQ，明天SeaJs火了，大家都要炒SeaJs了，所以我在KitJs里给jQ用户准备了一个语法糖(Suger.js)，完全模拟jQ API，当然除了作为一个纯技术范，深入了解一个技术是如何实现的要比takenism有趣得多。当然，如果你为了KPI考虑或者老板的项目奖金，直接复制Kit的组件代码，完成你的KPI，我不介意这样的行为。只要喝水的时候不忘挖机，和同事一起吹水的时候可以宣传一个KitJs。同时，Kit也是一个非常年轻的图书馆。由于它的不断发展，出现了一些bug和浏览器兼容性问题。我自己精力有限是必然的。在这个战火纷飞的时代，欢迎更多志同道合的同志朋友放大他，共同进步。

同时，kitjs的一个对话框组件今天发布，演示地址是http://xueduany.github.com/KitJs/KitJs/demo/Dialog/demo.html

工具包目录格式

言归正传，在KitJs中，kit.js作为Core核心文件而存在，它包含了一些最常用的Dom和Object，继承的操作，以及多个string.js、math.js等按照同一个目录中的函数划分进行扩展，以实现特定方向的函数扩展。每个独立的js文件都包含一个类的构造函数和一个全局对象的实例。

以kit.js为例，它包括$Kit类和$Kit类的实例$kit(以$开头，避免与常用变量冲突)。

其他类链接到$Kit和$kit实例实例，例如包含$Kit的math.js。数学类和$kit.math实例，从而确保在全球范围内只有$kit和$Kit污染。与此同时，在kit.js中，我们定义了一个名为$ kit.ui的命名空间，在物理目录下，与kit.js处于同一级别的Widget目录下排列着多个带大写字母的目录

widget目录下的所有目录都是kitjs的组件目录，每个独立的js文件只包含一个独立组件的类构造器(非实例)，可以兼容CommonJs的模块模式(可以符合commonJs的Modules/1.1规范，可以被AMD修改，具体的修改模式后面会详细提到)

(Kit组件的默认代码模板，注释符合jsdoc规范

让我们以对话框组件为例。每个组件类似于以下内容

第一个是jsdoc的注释，@class声明它是什么类，@require xxx.js声明它依赖哪些组件。

(3)构造函数和初始化方法

每个类在标准函数(config){}中定义一个构造函数。这里需要注意的是，默认情况下，每个kitjs组件的构造函数都会保留一个config参数作为个性化配置的输入。

同时，在类的构造函数中，有一个静态成员defaultConfig对象，用于存储kitjs组件的默认配置

使用kitjs组件时，首先需要借助new Instance初始化一个新的Instance对象，New Instance只初始化一个js组件对象，还没有HTML。需要执行init方法，创建HTML，添加到doc，相当于在灵魂上倾注血肉。

有的同学可能会问，为什么不直接把init方法放在构造函数里，而是单独放出来呢？

1是因为继承时需要实例化父类。当子类从父类继承时，子类的原型对象将被设置为父类的新Instance对象。如果将init的初始化方法放在构造函数中，将直接执行父类的HTML生成垃圾代码。

2因为考虑到延迟加载的情况，HTML代码需要在正确的时间执行，而不是在初始化时立即执行

所以使用kitjs组件的默认方式是

实例化后，执行init方法(init方法返回当前组件对象，返回代码为7)

从上图可以看出，dialog中的所有API方法都挂在prototype上，由prototype扩展继承并传递给实例对象

查看$kit.ui.Dialog.YesOrNo组件的构造函数代码。

(KitJs的继承

他通过$kit.inherit方法声明了与$kit.ui.Dialog对象的继承关系。在这里，有些同学会问，为什么要在构造函数中继承而不是直接在外面写呢？

原因是：

1.kitjs是一种基于原型的维护继承关系

2.要使用kitjs的组件，您必须实例化组件对象，并且每个组件都由一个新实例形式的构造函数创建

所以我把继承关系的执行放在了代码的构造函数中，这样当一个新的组件被实例化的时候，它就会遵循当前组件的构造函数的继承方法，一步一步的继承到他的父类的成员和方法。

当子类需要修改父类的方法时，只需要在子类的原型中定义一个同名的方法来覆盖父类的继承方法。

在命名方面，kitjs遵循子类将父类的类名延续为Namespace，如上图所示，$kit.ui.Dialog，$kit.ui.Dialog.YesOrNo

kitjs的继承实现也非常简单

实例化父类对象，将父类实例的所有成员复制到子类的原型中，然后将子类原型的构造函数重置为子类构造函数，然后挂起子类构造函数指向父类的链接。通过$kit.inherit方法，父类$kit.ui.Dialog.YesOrNo的所有子类都可以在子类$kit.ui.Dialog的实例化过程中被继承。

(5)配置参数，HTML和Css耦合的反汇编/蒙皮？

Kit的组件构造函数用于传入Map类型参数，并且从不个性化组件。当套件组件初始化时，它将使用用户提交的配置参数自动覆盖默认配置，并开始初始化。

对于任何组件来说，都无法摆脱的是HTML结构和Css风格的变化

Kit将这种耦合分解为config的参数配置，

首先是使用HTML模板技术。kit提倡使用$kit.newHTML方法直接根除HTML String，生成HTML DOM插入文档流。

因此，我们提取组件的一般HTML内容，将其打包到一个HTML String模板中，并将其存储在组件的defaultConfig中。如果用户需要修改HTML模板，他可以在初始化时使用自定义配置来覆盖默认defaultConfig中的模板字段。

在HTML模板和Css的耦合分解中，kit使用了一个技巧来按js模板分解className

通过init方法中的${xxx}到$kit.tpl将配置中的html替换为配置中的xxx

同时，所有样式都在css中设置，

如果需要切换多组皮肤，可以在初始化时通过config指定${cls}对应的实际类名，选择修改模板的className，达到换肤的效果。

(6)总结

基本上，通过对$kit.ui.Dialog.YesOrNo组件的代码分析，我们对kitjs的组件实现结构有了一个大概的了解。其实设计一个页面组件并不难，但是设计一个能够适应各种需求、快速变形、适应各种场合发展的页面组件是一个非常困难的要求。通过拆分HTML模板和Css，定制config参数和defaultConfig之间的协作，子类通过继承得到父类的属性和方法，同时根据不同的业务需求重构相关代码，基本可以灵活满足业务UI组件在各种级别、各种环境下的需求。

KitJs包括基础库和UI库。基本库：选择器功能、dom操作功能、动画功能、dom事件增强、hashtree数据结构添加、io功能、本地存储功能、多线程、范围等。还有一个模拟jquery操作格式的suger.jsUI库，包括：增强表单元素、弹出层、媒体播放器、验证框架、瀑布流、链接、幻灯片、日历等等