如果能做出来的话，一定会对整个国内前端开发有帮助；Core的实现采用函数变化的思想做的，另外是基于；我们看一个例子，在这个例子里面，我们用funct；我们不必像传统一样写js.name，自己触发事件；代码组织方式是模块化、颗粒化的，代码实现方式是抽；最后讲一下基于Mixin的UI组件构建；对于UI组件来说，我们中间加了一层UIbase，；举个例子，像over
如果能做出来的话，一定会对整个国内前端开发有帮助，并且希望大家一起维护这个meta层。
Core的实现采用函数变化的思想做的，另外是基于Base的组件开发，目前在Kissy里面遵守小巧简洁原则，组件开发有一个base，实现了eventTarget的功能，还有attribute功能，有了事件管理的话，可以添加事件，可以触发事件，也可以把事件移除掉，有了attribute的话，就可以get
set，可以触发事件。
我们看一个例子，在这个例子里面，我们用function Pig添加函数对象，添加了一个类目属性，它的value是未知的，我们让pig扩展base，最后看代码，你有一个Pig，当这个猪在shut的时候，内部就自动把事件触发出来，这是基于base的一个内部组件构架方式。
我们不必像传统一样写js.name，自己触发事件、自己维护，在这里什么东西都是半自动化了。
代码组织方式是模块化、颗粒化的，代码实现方式是抽象META层，通过publish方式变化，组件基础构建是Base。
最后讲一下基于Mixin的UI组件构建。在Kissy里，组件有两种，这种分类肯定没有问题的，一个是UI组件，一个是非UI组件，然后对于非UI组件就不多说了，这里有CSS组件，另外还有像数据延迟加载，比如说图片延迟加载，这些是属于功能性质，包括Flash创建、初始化工具，这是Flash模块，还有其他非UI组件，对于UI组件来说，目前有两种，一种是基于UI
Base的，有些不是基于UI
对于UI组件来说，我们中间加了一层UI
base有很多UI
base扩展类，比如说一个Box，有一个标准模块，包括在UI组件里面，比如说很多UI组件都有定位功能，在一定区域内要限制住，包括可拖拽的，然后还有master层，这里都抽离到UI
base扩展里面，实现了扩展。
举个例子，像overlay可以选择性继承UI
base的一个或者多个扩展，这样可以建成具体可用的组件，最后真正给用户用的组件，这个继承链不会太深的，像这个其实很深了，一般只有两层继承，像Dialog有三层继承。
base而言，里面的一些实现方式都是约定的，就是UI
base里面有一些方法是固定的，在一定时候去调用，比如说像constractor有重构，这里改变属性的时候，里面触发事件，调用set自动更新，改变一个UI内的X坐标，set
X然后一个值，会制动把坐标移动到位置处，不用关心怎么移动的，这是对于position的一个实现简单说明。
这是模拟C++的一个多继承，其实这个更多的是Mixin机制，在初始化的时候会先初始化父类扩展，然后是子类扩展，然后是子类，这和C++多继承是一致的，并且一般来说，这样可以省去很多用户不用自己写很多代码，很多代码框架都是帮你完成，帮你做的。
简单总结一下，我们为什么会采用这种方式做，一个很重要的，我们传统理念可能会去做面向对象做OO，可能面向类，要做得好的话，需要寻找一个很完美的类的继承数，其实这个
是非常难的，我记得之前有一个分享，下载很多电子书，电子书如何分类，这个问题很复杂，如何把你下载的成千上万本电子书去管理好，你要分门别类，可能不是一级目录、二级目录要解决的，有时候要四五级目录才能解决，这并不是每个开发人员这么做，这么做的代价非常大，所以最好的一种方式，直接加TAGS，在Gmail里面，它的邮件管理不支持你自己去建一个邮箱的，但是你打TAGS的方式，其实不需要你去构建一个类，去分门别类做一些东西，你只要知道当前这封邮件有哪些TAG就行了。
对于我们来说，我们关注一个对象，其实我们不需要关心这个对象是狗还是猪，其实没什么关系，我们只需要关心我们调用这个对象方法的时候，是不是能够按照预期工作，这是最关键的，从这个出发的话，在JavaScript
里面，我们可以模拟单继承，但是这种单继承的话并不好用，特别在UI组件去构建比较复杂的时候，你发现如果采用单继承的话，如何分类，比如说你的popup是属于UI类，对于一个popup和dialog关系是怎样的，要理出一个清晰头绪是非常困难的，在EST里面，先是一个pattner，然后里面的继承管理是有五六层的，这里的继承关系可能并不是很好。
这里是shap度继承，加上选择性mix进来，还有一个，我们在实现UI
base扩展的时候，很多时候约定优于配置的，我们采用约定的方式，有些东西约定好就行了，如果可配置、可灵活的话，有时候未必是好事，很多时候是约定优于配置的，这样继承的好处很明显。
我们之前经常两个UI组件里面出现重复代码，这些重复代码应该如何管理、如何去抽象，这就很头痛，资深程序员A和资深程序员B的想法是不一样的，他们不能说谁对谁错，每个人对世界看法不一样的，所以通过把这种深层次类继承数概念去掉的话，当团队很大的时候，多个成员之间的协作变轻松了。
不足之处在于如果一个UI组件比较复杂，他可能继承很多UI
base扩展，每个UI
base扩展有很多方法名，base到UI对象的时候，如果成员名是相同的，这时候会引发冲突，但这种目前因为Kissy里面是自己去维护的，所以这个冲突通过内部去解决就可以了。
另外基于UI
base写扩展，开发者必须自己提前知道这一套游戏规则，这个游戏规则要去了解、去熟悉，这个门槛有一点高，但是应该也还好，大家都喜欢玩游戏，玩的很溜，你只要把这套游戏规则熟悉了，很快就可以去写的。
最后说一下Kissy的一个展望，这个图是最初Kissy开发时候的一个设想，分成三个阶段，第一个阶段是基础核心，这是最基本的部分，包括seed，包括Core，这部分实现功能就是一个JQuery的功能，然后是常用组件，在日常开发中，在项目开发中经常需要使用的功能性组件和UI组件，这是常用组件部分。
其次要尝试做到社区化，并且做一些子品牌，这是Kissy的一个roadmap三个阶段。
目前除了Kissy，Kissy是属于Kissy
team的子项目，和Kissy平级的还有上面列出来的项目，比如说Kissy
library项目，一个类库不仅减少开发脚本工作量，还有减少写HTML工作量，另外像Kissy
editor，这是Kissy的副文本编辑器，已经发布2.0版本，大家有兴趣可以看一看，包括Kissy-ajbridge为，比如说要实现多文件上传功能，在ajbridge里面有的，包括还有Kissy-tool，还有其次有一些文档，这是项目角度看整个Kissy
team现有工作。
其次可以换一种视角看，从这个视角，Kissy包括有原码、文档、规范，目前规范还不是很全，但逐步会完善起来，其次有流程，像在Kissy里面开发一个组件，我们推荐分三个步骤，先要预言，达到40-50%的时间，想清楚之后写代码，这是开发阶段，开发完成之后还有一个发布阶段，这三个阶段都走一圈之后，整个Kissy组件才叫开发完成了。
目前Kissy项目里面的工具，比如说自动打包通过Ant，包括是Google
compiler，这个确实非常好用，强烈推荐大家使用，还有像单元测试的一个框架，那个Jasmin这是优秀的BDD测试框架，非常值得去使用，还有一个文档生成工具，Kissy
Team还有一个博客，还没有什么内容，以后更新的时候，会在Twitter上告诉大家。
经常我会收到一些邮件，邮件里会有人提要求，能不能够把Kissy打一个包发给他，我说已经放在Github，他还给我回邮件，他说他不信，这里我要说一下，Kissy真的是全部已经放在Github里面，没有任何内部respons和外部respons的区别，这个确实彻底的开源。
目前Kissy的维护开发，固定成员是有五个人，除掉固定成员之外，还有一些人参与进来，不固定的大概有七八个，当你往Kissy里面提交了代码，通过Github可以看出你的贡献，比如说图上所示的就是不同成员什么时候提交的代码，这是贡献值，我非常期望大家如果对于Kissy有兴趣，发现Kissy的一个BUG，首先可以反馈给我们，其实如果你有时间，你可以自己尝试修复，并且修复之后直接提交给我们，我们可以直接把你的代码弄进来，这样你的名字也就留在这里，非常期望大家都参与进来。
上面所有这些，其实Kissy目前虽然说已经发布1.1版本，很快发布1.2版本，这一切还不是一个终点，也不能算一个里程碑，这只是一个刚刚开始的地方，我们正在努力做这样一件事情，希望把Kissy类库做好，让这个Kissy类库对业界，对整个国内前端有所帮助，这是我们的一个起点。
现场提问：
我注意到这里可以把JQuery的东西弄进来，后面注意到Kissy的做法脱胎于YUI3，像这种UI或者base这种东西，UI里面已经实现过，如果我有一个方式可以把JQuery给mix进来的话，像mix
JQuery一样，把UI很多东西mix进来的话，是不是？
这个想法很好，我自己也想过，后来放弃了，它有一套构建体系，这套构建体系很好，但还是太复杂了一些。
现场提问：
我的意思Mix的地方，Kissy和YUI很大不同的地方就是在于MIX，因为看到还是有很多一直很重复的东西在制作。
但是这个mix的话有一点没讲，被mix的类库组件是有条件的，并不是所有东西都能够mix进来，有的mix规范，对mix对象要满足一定条件，比如说组件是一个独立的东西，然后有
一套约定的接口，只使用一套有限接口，把这套接口通过Kissy
Core做桥接过去，然后把整个YUI组件接过来，中间要做一些工作，看值不值，这个工作量很大，做下来还不划算，我个人不是很赞同通过MIX的方式把YUI3弄进来。
现场提问：
我有两个问题，UI组件开发的时候，你们继承UI
base，接口通过文档约定形式吗？它有几个UI生命周期，有几个固定方法，是规定所有开发人员一定要用这种方法，还是通过代码方式，比如你非得要继承这个，你一定要实现？
选择性实现，你一旦要实现其中某个功能的话，你必须用这个名字，如果你这个组件不需要用到这一步的话，可以省掉。
现场提问：
也只是一个约定？
现场提问：
不明白meta层的作用？
对用户来说，其实是无所谓的，但是对于我们类库开发者来说，如果我们采用meta层写的话，我们可维护性提高很多，如果我把attr写进去，里面有一个effect，这些判断是统一的，不管是attr还是CSS，里面很多逻辑都是一致的，通过这种方法，把相互逻辑抽离出去，放在统一的地方。
现场提问：
能不能说一下多继承的方法？
你可以在任何对象添加一些需要的方法，多继承说白了也是mix，就是往它的原形mix需要的功能、需要的方法。
现场提问：
感觉有点像单继承。
之所以叫多继承，因为里面加了初始化的过程，比如说一个子类继承父类，父类有很多扩展类，如果单继承的话，那么在子类初始化的时候，只会调用副类的构造器，但目前副类还有一堆UI
base的扩展，在这种方式下，当你初始化一个子类的时候，会有一个顺序，把副类的那些扩展也都初始化了，按照一定方式初始化，从实现机制上讲，其实就是和C++多继承顺序是一致的，他们的实现方式不一样的，但最后达到的效果是一样的，是从这个角度讲
现场提问：
能解释一下publish吗？
我们看演化3里面，可以把get
attribute里面看一下，这里get和set非常容易写，逻辑非常清晰，通过publish，给publish传一个参数，就把里面的逻辑封装起来，当有两个参数的时候是Get，当有三个参数的时候是set，把里面的逻辑封装起来放在publish方法里面，这个publish不管你是get
attribute还是get
style，都是可以抽离出来的，就是做了一层函数变换。
现场提问：
这是类似于自定义事件吗？
这和事件没有任何关系，就是把一些方法转到公共API里，就是把方法调用，转来转去，其实做了一层封装。
现场提问：
问一下mix的问题，你说mix就像吸星大法一样，把不同类库引用过来，如果想用的时候，同时用了两个类库里面有相同命名空间，导致冲突，这时候你们怎么处理这个冲突？
还有一个问题，你这边有大量继承复用的方式继承组件，可能在不透明的东西引进来之后，怎么让开发人员更好的控制住代码质量，会不会出现一行隐藏事件绑定，触发额外事件？
第一个问题是冲突的问题，确实有时候会冲突，比如说我们不管通过SVN或者说Github管理代码，都可能引发冲突，系统能做的事情就是提示，告诉你两个文件冲突了，然后具体我们开发者要选择怎么去解决冲突，这是开发者自己决定的，你说mixA、mixB，A方法和B方法冲突了，保留A还是保留B，这时候是由当时场景下开发者决定的，这是看开发者保留哪一个。
现场提问：
第一个问题也是meta的问题，我有一个方法，有两种情况，一个是传字符串，一个是传函数，通过meta区分开来可以吗？
这个可以的，publish里面最后一个说明，其实里面可能是经过了很多层函数变换，publish里面，PPT里讲的可能是做了get和set的转换，同时一些参数是字符串，参数是函数，你可以封装成一些通用的方法，通过这些方法做变换，因为最后肯定可以通过某种方式去把你需要的东西变换出来，我们把一些通用变换抽离出来。
现场提问：
三亿文库包含各类专业文献、专业论文、生活休闲娱乐、外语学习资料、文学作品欣赏、应用写作文书、高等教育、59“第5届D2前端技术论坛”(下午)等内容。