邀请第三方团队开发页面装饰器实现的公开信。

邀请第三方团队开发页面装饰器实现的公开信

页面装饰引擎简介

用于装饰朴素html元素的框架，使用简单的xml标记，标识期装饰行为，比如将一个普通的input装饰成一个日期输入控件。将一个textarea装饰成一个代码语法高亮显示区域，或一个wysiwyg html编辑器。 JSI启动后将采用异步方式，自动检查decorator标记，自动做相关类的寻找、导入并装饰页面。
实现零脚本代码的web富客户端编程：

更多信息参考：
示例装饰器演示：http://www.xidea.org/project/jsi/decorator/index.html
JSI项目主页：http://www.xidea.org/project/jsi/index.html
JavaEye JSI专栏：http://www.iteye.com/subject/JSI

适用范围

页面装饰引擎是用来装饰普通网页的框架，只需要在普通网页上增加相应装饰标签，即可实现富web客户端的常用功能。保持页面简洁、优雅的同时，享受页面通用组件带来的便捷。
同时，正因为它的简单性，使用装饰引擎的页面，后期维护也更加简单。
在开发效率优先的项目中，其优势尤为明显。当能，对于非常非常复杂的页面，导入JSI托管类库直接编程的方式也许更加适合。

现状分析

页面装饰引擎是一个工作于JSI上的可实现零代码编程的RIA解决方案。
JSI项目已有一年多的历史，在类库管理，按需装载方面，技术已经非常先进；
其中无侵入的脚本管理，我们是最完善的；2.0提出的异步装载技术，同类框架中也只有JSI2能做到。

当今业界，在RIA操作的火热的时候，JSI提出装饰引擎这个优雅简洁的RIA解决方案。
我认为，只要我们可以尽快推出完善实用的装饰器集合，完全可以在业界占领一席之地。

目前我们已有一个简单示例实现集，不够丰富，而且都还是初级阶段，不够完善。
现在发布的这些装饰器，主要是为了演示JSI装饰引擎的工作方式，编码风格。

参考

JSI装饰引擎工作原理介绍：

1. 云想衣裳花想容－－JSI组件模型介绍（二）

JSI装饰器编写示例：

1. 基于FCKEditor 开发JSI Editor装饰器
2. 从零开始 Spinner（微调器）装饰器开发

结语

目前就我一人之力，开发一套完整的装饰器，尚需时日，并且由于本人缺乏ui设计的天赋，在这里很难有出色的表现。
所以，我希望能邀请到第三方团队、公司在这个基础上开发出自己的更加实用的装饰器集合。同时我可以空出更多的时间去优化核心模块。

JSI及其装饰引擎采用LGPL开源协议。可以商业应用，当能，更希望能开源。

对于开源第三方的实现，我可以提供充分的技术支持。并配合其宣传，推广。
对于商业实现，可以提供必要的技术支持，并提供JSI专用的脚本混淆工具，保护您的知识产权。

我的联系方式（email&msn）：jindw◎xidea。org

评论

14 楼 bubble 2007-08-28  

DSONet 写道

提几个问题，大家讨论。
在宽带的带宽越来越高的现在[我家里就是2M的]，是研究一个按需加载的框架的优秀性重要，还是研究126.com的前端设计是如何完成的更有意义？

这哥们显然是有些不太着吊，你像日本人那样100m光纤到户，这些问题都ok，我把js搞的2m都没问题，你家里是2m，不是所有人都是自己独享2m的

13 楼 bubble 2007-08-28  

我说句真心话，我想看到的是把ext用xml标签封装，加入这个成功了，我第一尝试把jsi用于项目中

12 楼 jindw 2007-08-20  

DSONet 写道

提几个问题，大家讨论。
在宽带的带宽越来越高的现在[我家里就是2M的]，是研究一个按需加载的框架的优秀性重要，还是研究126.com的前端设计是如何完成的更有意义？

这点我也注意到了，在脚本库不算庞大，带宽够高的时候，单是这点确实意义不大。

DSONet 写道

btw，JSI据说提解决命名污染问题方案，那么如果有这么两个类，在org.xidea.eg.EventTest中要同时使用YAHOO.util.Event和com.javaeye.events.Event类，如何编写package文件呢？

JSI解决命名冲突，主要是避免一些烦杂的间接依赖的类库之间的冲突；
直接依赖相对很少，正常情况下也不会有单一脚本直接依赖有名称冲突的情况。


这个功能点与JSVM相似。
举例：
我们可以让一个类库同时直接依赖Scriptaculous和jQuery，我们不受jQuery和Prototype冲突的影响。

但是，如果要让你的类库同时直接依赖 Prototype与jQuery，那么我们还要收到两个$函数引用被覆盖的影响。
解决办法：
申明依赖之后，在使用$函数的地方，重新使用一下$import函数（$import不会重复装载，对于已经装载的类库，他只是重复一下属性赋值操作），将$函数导入到指定容器，有点丑陋：（
不过暂时也想不到更好的办法。

11 楼 DSONet 2007-08-19  

btw，JSI据说提解决命名污染问题方案，那么如果有这么两个类，在org.xidea.eg.EventTest中要同时使用YAHOO.util.Event和com.javaeye.events.Event类，如何编写package文件呢？

10 楼 DSONet 2007-08-19  

提几个问题，大家讨论。
在宽带的带宽越来越高的现在[我家里就是2M的]，是研究一个按需加载的框架的优秀性重要，还是研究126.com的前端设计是如何完成的更有意义？

9 楼 jindw 2007-05-09  

我对dojo的了解确实很浮浅，在它早期的demo上，有很严重的阻塞问题，因此而引发上述推测。

我想，如你所说，产品阶段，dojo必须吧所有用到的脚本打包成单个文件。

现在，这种变通的解决办法，也是出于一种无赖吧。因为不打包，它就无法解决阻塞问题。

而我在JSI中，因为可以解决阻塞问题，所以我只要打包部分常用类库即是。特别是用到第三方类库的时候，我也不想把他们都打包。

8 楼 radar 2007-05-09  

jindw 写道

说句心里话，我讨厌和dojo相比。
你提到，那我就解释一下：
1、dojo widget我没怎么用过，但是你一说到dojo的性能问题，有一个地方是不容忽视的：
dojo在requrie函数做真正的按需装载脚本时（装载没有缓存的脚本），只能采用XMLHttpRequest同步方式装载，而这种方式将阻塞浏览器，严重影响用户体验（浏览器停止事件响应，甚至停止窗口重绘，就像死机）。我想，不少抱怨Dojo性能问题的，都缘于此吧。

谁说在dojo产品阶段require需要同步加载脚本的。为什么不打包成一个大的js文件。
关于dojo的很多抱怨是因为不了解dojo。
dojo确实很复杂，但可以抱怨复杂，但不能随便指责不是问题的问题啊！（不是说楼主啊）

jindw 写道

关于同步装载的弊端，我在另外一个帖子里说的更详细，有例子，你可以试试：
脚本安需导入(装载)的三种模式的对比：http://www.iteye.com/article/66702
关于JSI组建模型的性能，我在一个回帖里有详细说明，有测试数据：
http://www.iteye.com/post/265834

我看过。但dojo默认的是同步加载。你完全可以自己打包你的dojo.js啊？

jindw 写道

2、装饰器，只是提供一种组件启动的接口，装饰完了，怎么处理，由组件负责。问题在于我们的数据源一般是当前元素下的html；所以看似无法装饰动态数据，但是，组件是活的，它既然可以接受html数据源，复杂一点，接受外来数据源，更新自身也不是不能。

我没有说你的方法不好。我只是指出，你与dojo的方式很类似，但dojo遇到问题了。希望你可以提前考虑。

jindw 写道

radar 写道

另外关于加栽脚本，反正总的时间是一样的。

问题是，对于打包成单个大文件的方式，很多简单页面装载了太多没必要的资源。而不打包成单个大文件，零碎的脚本标记又会使页面非常复杂。

dojo的包机制也不是完美的。甚至可以说很有问题。我感觉最好的是按 function打包。但这简直是不可能的。



http://www.coloradohomestop.com/Search2.aspx
看看这个dojo应用，能说慢吗？

7 楼 jindw 2007-05-09  

radar 写道

只需要在普通网页上增加相应装饰标签，即可实现富web客户端的常用功能。保持页面简洁、优雅的同时，享受页面通用组件带来的便捷。

和dojo 以前的 widget太相似了。只是dojo在 window.onload做了所有的工作，你搞了个 loading挡主了，思路我估计差不多。

我感觉dojo widget最终栽在两个方面
1、性能，页面中需要太多装饰怎么办
2、动态的怎么装饰，如果你提供可排序的表格，更新表格数据，你怎么装饰。

说句心里话，我讨厌和dojo相比。
你提到，那我就解释一下：
1、dojo widget我没怎么用过，但是你一说到dojo的性能问题，有一个地方是不容忽视的：
dojo在requrie函数做真正的按需装载脚本时（装载没有缓存的脚本），只能采用XMLHttpRequest同步方式装载，而这种方式将阻塞浏览器，严重影响用户体验（浏览器停止事件响应，甚至停止窗口重绘，就像死机）。我想，不少抱怨Dojo性能问题的，都缘于此吧。

关于同步装载的弊端，我在另外一个帖子里说的更详细，有例子，你可以试试：
脚本安需导入(装载)的三种模式的对比：http://www.iteye.com/article/66702
关于JSI组建模型的性能，我在一个回帖里有详细说明，有测试数据：
http://www.iteye.com/post/265834

2、装饰器，只是提供一种组件启动的接口，装饰完了，怎么处理，由组件负责。问题在于我们的数据源一般是当前元素下的html；所以看似无法装饰动态数据，但是，组件是活的，它既然可以接受html数据源，复杂一点，接受外来数据源，更新自身也不是不能。

radar 写道

另外关于加栽脚本，反正总的时间是一样的。

问题是，对于打包成单个大文件的方式，很多简单页面装载了太多没必要的资源。而不打包成单个大文件，零碎的脚本标记又会使页面非常复杂。

6 楼 radar 2007-05-08  

另外关于加栽脚本，反正总的时间是一样的。

5 楼 radar 2007-05-08  

只需要在普通网页上增加相应装饰标签，即可实现富web客户端的常用功能。保持页面简洁、优雅的同时，享受页面通用组件带来的便捷。

和dojo 以前的 widget太相似了。只是dojo在 window.onload做了所有的工作，你搞了个 loading挡主了，思路我估计差不多。

我感觉dojo widget最终栽在两个方面
1、性能，页面中需要太多装饰怎么办
2、动态的怎么装饰，如果你提供可排序的表格，更新表格数据，你怎么装饰。

4 楼 jindw 2007-05-08  

Lucas Lee 写道

.........................

我认为脚本的依赖管理，及脚本压缩、按需装载，都是在UI组件很丰富并且导致脚本文件很大之后才显得重要的。但是当前似乎还不是时候，所以这样的特性也许比较超前，但是目前并不是关键问题。

脚本的依赖管理，在程序达到一定复杂度的时候，将非常有必要。依赖的暴露，将使程序复杂度徒增，二次开发难度影响更是明显。很多细节，完全没必要让类库使用者知道。让费人家的脑细胞。

按需装载在一些封闭的框架中，一般作用不是太大。只要不是太大，大不了把自己的脚本打包到单个文件里。
但是，JSI是个开放的框架，框架的开发者不可能知道用户到底会用到那些类库，jQeuery？prototype？FCKEditor？YAHOO UI？ 我总不可能把这些统统打包吧。
此外，脚本也不单是下载时间，还要解析，一次性装载太多的脚本，也算一种让费吧。

3 楼 LucasLee 2007-05-08  

jindw 写道

Lucas Lee 写道

看了一下你的网站和例子.
我发现一个问题: 目前最大的困难不是如何组装或者如如何使用UI组件,而是UI组件本身少,不完善,功能弱.
我说的UI组件目前除了HTML内置的哪些外,就是用Javascript等技术实现的.
你的项目中用标签来描述如何装饰一个现有组件以达到更多的功能,路子还可以,但是你把最大最复杂的部分留给了第三方,或者说你的项目似乎没有把主要精力放在我们最关心的问题上.

以上仅是我个人的想法,如有不当,请指正.

你的观点我不能认同。
时间做证。现在能见到的这些装饰器，虽然很简单，但是，那是我用两周左右时间完成的。
而JSI的内核（依赖管理、按需装载部分）和它的装饰引擎，我花了一年多时间（其中，自2007年开始，全职投入）。


当能，最能吸引人眼球的，就是页面组件了。不过最复杂的也是最强大的部分，应该算JSI的依赖管理。

我自2006年初开始利用业余时间开发JSI1，年终左右，基本完成（实现了脚本级别的依赖管理，及同步按需装载）
之后在家全职开始JSI2的开发，目前也只完成了一个预览版（实现对象级别的依赖管理，及非阻塞延迟装载和异步装载）。
当能也有一些时间在做工具开发，如JSI的文档自解析工具，脚本压缩工具，等。


对于这种页面组件模型来说，按需装载是有必要的，而在JSI出现之前，没有一个能够实现异步装载的开源脚本管理框架。
而同步装载会导致阻塞问题，将严重影响用户体验。

JSI组件模型，自设计开始，就做着使用第三方组件的打算：
首先，在JSI的设计上，无侵入性，可以轻松加入第三方代码。
其次，装饰器指示需要装载的脚本资源时，provider属性，就是为了单个页面，同时使用多个组件供应商而起。

我认为脚本的依赖管理，及脚本压缩、按需装载，都是在UI组件很丰富并且导致脚本文件很大之后才显得重要的。但是当前似乎还不是时候，所以这样的特性也许比较超前，但是目前并不是关键问题。

2 楼 jindw 2007-05-08  

Lucas Lee 写道

看了一下你的网站和例子.
我发现一个问题: 目前最大的困难不是如何组装或者如如何使用UI组件,而是UI组件本身少,不完善,功能弱.
我说的UI组件目前除了HTML内置的哪些外,就是用Javascript等技术实现的.
你的项目中用标签来描述如何装饰一个现有组件以达到更多的功能,路子还可以,但是你把最大最复杂的部分留给了第三方,或者说你的项目似乎没有把主要精力放在我们最关心的问题上.

以上仅是我个人的想法,如有不当,请指正.

你的观点我不能认同。
时间做证。现在能见到的这些装饰器，虽然很简单，但是，那是我用两周左右时间完成的。
而JSI的内核（依赖管理、按需装载部分）和它的装饰引擎，我花了一年多时间（其中，自2007年开始，全职投入）。


当能，最能吸引人眼球的，就是页面组件了。不过最复杂的也是最强大的部分，应该算JSI的依赖管理。

我自2006年初开始利用业余时间开发JSI1，年终左右，基本完成（实现了脚本级别的依赖管理，及同步按需装载）
之后在家全职开始JSI2的开发，目前也只完成了一个预览版（实现对象级别的依赖管理，及非阻塞延迟装载和异步装载）。
当能也有一些时间在做工具开发，如JSI的文档自解析工具，脚本压缩工具，等。


对于这种页面组件模型来说，按需装载是有必要的，而在JSI出现之前，没有一个能够实现异步装载的开源脚本管理框架。
而同步装载会导致阻塞问题，将严重影响用户体验。

JSI组件模型，自设计开始，就做着使用第三方组件的打算：
首先，在JSI的设计上，无侵入性，可以轻松加入第三方代码。
其次，装饰器指示需要装载的脚本资源时，provider属性，就是为了单个页面，同时使用多个组件供应商而起。

1 楼 LucasLee 2007-05-08  

看了一下你的网站和例子.
我发现一个问题: 目前最大的困难不是如何组装或者如如何使用UI组件,而是UI组件本身少,不完善,功能弱.
我说的UI组件目前除了HTML内置的哪些外,就是用Javascript等技术实现的.
你的项目中用标签来描述如何装饰一个现有组件以达到更多的功能,路子还可以,但是你把最大最复杂的部分留给了第三方,或者说你的项目似乎没有把主要精力放在我们最关心的问题上.

以上仅是我个人的想法,如有不当,请指正.