在JSI中打包脚本类库。
目前只有jar方式，同时支持java和php。
我还想支持一种文本的格式，这样还可以方便的做适当修改。
其实jar也好，zip也好，都是一个键值对系列的存储方式，这种格式从逻辑结构上讲，与java的Properties文件类似。
Properties文件在jdk5之后支持xml方式，这对于中文来说，是一个很好的消息。
我想，我与其自己定义一个jsi专用的格式，还不如拿来主义，直接用
http://java.sun.com/dtd/properties.dtd ？
还有就是类库路径的约定，我暂时的想法是。
scripts目录下支持 xml格式类库。
WEB ...
前端时间这里出现了不少讨论前端模板的帖子。
我还是原来的观点，前端要做模版，最好不要带上解析开销。
一旦带上了解析开销，那么为了性能，我们必然会考虑很多很多，很多事情不敢做不能做。这可能造成很多事情不能去处理。模版的易用性也会大打折扣。
而且一旦你在前端运用了模版，说明你的前端运用已经达到一定的复杂度，如此一来，机器辅助的代码优化，就应该排上日程。
这一个过程中，如果我们能吧模版数据顺带解析成一种更有利于下次解析的方式， 那么性能问题就可以解决。
近来我也在写一个前端模版引擎，这一模板引擎计划在JSI的下一代装饰引擎中使用，而且这些东西都将得到 JSA 支持，在以后的JSA压缩过程中 ...
开始发帖错误，我的测试不够严谨。
经过测试，IE也没有踩到那个地雷，只是我测试的时候刚好发生了另外一个错误。
那就是直接出现了“</script>”字符串。这个问题导致压缩结果不能直接粘贴到html中（一般的做法，放到js中是没有问题的）。
不过这也确实是个问题，这辆个问题都是问题，前者已经解决了，后者我也将在下次发布之前解决。
原帖：
引用错误原因：http://hi.baidu.com/jindw/blog/item/6aa695355835e11491ef39d6.html/cmtid/47dd9618b4531cb14aedbc90
这个错误已经在新版本的JSA中 ...
部署到Tomcat中，打开script目录，可以显示你当前script目录下全部托管脚本的API试图。
导出功能介绍：
导出成jsidoc文档 （单个文件）
合并脚本（可以选择不同的隔离级别）
准备编写JSI的外围元素，先整理一下编码风格和一些约定，欢迎大家讨论。
基本风格
* 基本参照Java代码风格。
1. 驼峰式命名（单词无连接字符，单词首字母大写，其余小写）；
2. 类的首字母大写(eg:MyClass)；
3. 变量名，方法名，成 ...
演示地址(目前只支持Firefox): http://www.xidea.org/project/jsidoc/
基本功能
API查阅:
该程序可以通过脚本源代码及注释,自动适时生成对应的JavaScript API文档。源码浏览:
你可以通过API文档内连接,进入相关实现代码。脚本导出:
导出工具可以更据JSI的包文件,以正确的顺序,自动导出选中的脚本元素及其依赖。
出自该贴的回复:
http://www.javaeye.com/topic/161609
JSI的延迟装载和异步装载过程非常相似.
他们的实现是这样的:
1.计算出全部未装载的依赖,并将依赖加入缓存.
2.执行同步装载.
其实所有的三种装载方式,原理都是一样的,只不过非同步装载在真正装载前有个预处理.
而异步装载和延迟装载的区别也就在于预处理过程中如何缓存脚本.
异步装载就是直接xhr异步读取js文件,加入JSI的脚本缓存.
而延迟模式就略显麻烦了,如hax所言,他是通过打印一段引用脚本,脚本文件的内容就是用闭包封起来的源代码.
$JSI.addCacheScript("mypkg" ...
JSIDoc是我一年前开发的用来解析JS文档的纯客户端脚本程序。
现在随着JSI2的重构，已经好久没有跟进了，今天回头看看。
很多设计实在是失误，记录一下：
SourceEntry作为ECMAParser的子类：非常失败，导致SourceEntry非常复杂，回头一看，头大！
如果使用组合，这种局面就不会发生。
总结：不要滥用继承。特别是JavaScript这种弱类型语言，成员多了，鬼知道他们在干什么。
JSDoc作为类：算是比较失败吧，如果用单例，很多东西可以简化。
总结：不要总去假设一些没有的需求，宁可新需求到达后重构，甚至重写。
改动
2.0方式：
$import(path,callbackOrLazyLoad,target)
调整成(将target参数提前)/** * @param <string> path (package:Object|package.Object|package.*| scriptPath) * @param < Object> target
可选参数，指定导入容器。 * &n ...
先回顾历史：
JSI1（2006-2007）是个简单的框架，只有脚本级别的依赖管理，只有阻塞同步装载模式。
JSI2 （2007-2008）是个庞然大物，同步装载，异步装载，延迟装载，装饰引擎。。。。。
网撒的太宽，而且学习曲线也非常陡峭。
JSI2.1 新的2008，JSI2也打算做点改进。
时至今日， JSI已经有两年多的历史了，自己也在大大小小的项目中有了不少实践，普遍的反映是。内核庞大。依赖管理复杂，难以掌握。
确实，JSI的依赖管理非常复杂，而且内核源码的组织也不够完美。装饰引擎，异步装载，等等，全部混合在一起，别说他人，我自己看着也头晕。当时的借口：压缩优化 ...
1。保留字滥用
如果你的脚本中存在某些保留字或者关键字属性甚至变量名，那么，对不起，您的脚本无法通过解析。
虽然大多数浏览器在这个时候会对你宽大处理，但是JSA不能，比如新浪编辑器里有一个float属性（其实那是错误写法，正确写法应该为styleFloat）
2。严格的正则语法
JSA使用的是Rhino语法解析器，在正则处理时，哪怕在[]号内，依然需要对全部特殊字符转义。否则可能会出错。
比如，如下表达式：
/[/]/.test('/')
它在大多数浏览器上，都能通过。
但是Rhino解析器，则无法通过。
我粗略过了 ...
直接合并－－传统方式
根据脚本依赖关系，组织好导入顺序，简单的合并成单个大文件。
这是最常见简单功能的一种合并方式。通常也不需要任何工具的支持。由程序员手动完成。
优点：简单
缺点：需要程序员自己管理脚本名称冲突。
间接依赖全局变量的隔离－－JSI运行时等价的隔离策略
就是说，比如你在脚本包p1有一个脚本A 依赖脚本元素B，脚本元素B依赖仍外一个脚本包p2中的脚本元素A,如果你采用直接合并的话，两个包中都有一个名为A的元素，直接合并一定会产生冲突。
这时，就需要我们在最后导出发布脚本时，做好这种隔离操作。
如：我们正真直接使用的只是p1包中的A，那么这些元素导出前后变量名映射可能是：
A( ...
昨晚忙到三点半，加上今天一天，我重构了一下JSA以前的代码。
增加了对全局变量混淆的设置，
公开了部分API调用接口。
方便于二次开发
现在邀请大家测试测试。
国庆前说了要完成的事情，拖到现在^_^
补充：20071022凌晨改进版发布
完善了操作语言切换，并且在非安全区域外混淆提供了更友好的用户界面。
* 类库导出支持（完全脱离JSI环境）
从JSI托管类库中，选择文件/对象集，导出为单一脚本文件，完全脱离JSI装载环境。
也就是说，届时JSI不仅可以作为一个运行时的脚本管理框架，也可以当作一个部署时的脚本定制、打包工具。
我是看Ext的定制工具后产生这个想法的，JSI的依赖定义API完全可以用作一个通用的脚本定制、打包工具的依赖描述语言。
* Ext集成（延期。。）
集成Ext，一方面可以弥补JSI组件的缺乏。另一方面可以优化Ext的装载延迟。
ext目前大小为：462,031字节，JSI2Alpha版的内核为35,140字节，不到Ext的十分之一（文件大小均在文 ...
装载效率测试
测试页面见：test/load-eff-test.html
为了测试结果更显客观，我选择了第三方类库的装载测试：
'com.yahoo.yui.*',
'net.conio.prototype.*',
'net.fckeditor.*',
'org.jquery.*',
'us.aculo.script.*'
共22个脚本文件（对于JSI来说还有诺干包定义文件）。
FF2:
标记导入时间（原始方式）:469,469,1047,484,484,437,469,484
同步导入时间:469,453,484,437,469,453
延迟导入时间:921,765,891,906 ...
JSI2Alpha及JSA1beta 发布：
引用JSI简介：
JSI 是一个 开放的、无侵入的 脚本库管理框架，内核不提供任何具体功能，有一些功能子项目，如网页装饰引擎。
JSI2性能测试报告：http://jindw.javaeye.com/blog/93118
更多信息请查看：http://www.xidea.org/project/jsi/
JSA简介：
JSA最初是做JSI编译处理的一个小工具，现在也可以用来混淆、压缩脚本。支持swing和ant task两种工作方式。
可以通过webstart启动：启动JSA（允许访问文件系统），沙箱内运行（功能受限）
这次发布的J ...
引用JSI 自身提供一些常用API，数量极少，尽量以一种正式的风格提供，尽量回避争议。
有些是启动文件用到的，如任务队列支持，还有如装饰引擎直接用到的，如BrowserInfo、EventUtil、StyleUtil等。
对于启动文件中未直接用到的，如果风格的争议太大，都将剔除出去。
BrowserInfo对象：
/**
* BrowserInfo 对象，用于判断浏览器的相关信息，如浏览器类型、quirks模式、客户端语言（简体中文？英语..未实现）、操作系统（未实现）等等。
* @public
*/
var BrowserInfo = {
isIE : falseChe ...
装饰引擎简介：
系统默认的装饰引擎为：org.xidea.decorator.DecoratorEngine。
JSI装载后，将做如下操作：
判断有无装饰器命名空间声明（xmlns:d= "http://www.xidea.org/taglib/decorator"）
若有，将在文档装载结束后，启动装饰引擎，初始化当前可用的装饰提供者表。（装饰提供者是一个JavaScript包，在注册这种装饰包时可同时指定他的别名，别名*表示默认包）
遍历当前文档，凡是该命名空间的节点，都被看作需要装饰的元素。若当前文档存在装饰元素，启用遮罩（关机效果 ...
JSI组件模型是一种用来装饰简单html元素的框架，使用简单的xml标记，标识其装饰行为，比如将一个普通的input装饰成一个日期输入控件，将一 个html ul标记装饰成菜单或树，将一个textarea装饰成一个代码语法高亮显示区域，或一个wysiwyg html编辑器。
JSI启动后将自动检查decorator标记，构建层次结构，自动做相关类的寻找、导入和装饰操作；实现零脚本代码的web富客户端编程。
代码示例：
日期选择器 (DatePicker):
<d:datepicker> ...
Java的成功，离不开它那个庞大的类库，不单是sun的类库，很多细节的实现都取自第三方（如xml解析采用Apache的实现）。
如前言所述，我们暂时不大算编写丰富的公共API，但是我们可以集成其他成熟的类库，同时隔离他们的依赖，隔离各个脚本的执行上下文，消除命名冲突的危险。
这里我们详细介绍一个复杂一点的实例：类似Windows XP文件浏览器左侧的滑动折叠面板(任务菜单)效果。
我们先集成Scriptaculous Effect类库，并且在这个基础上按我个人的习惯对一个面板折叠效果做一个简单的封装，展示框架的类库封装功能。
1。集成Scriptaculous类库：
...
众所周知， Scriptaculous所依赖的Prototype库与jQuery存在冲突。所以同时使用比较困难。
JSI针对每一个装载的脚本都有完全独立的执行上下文。所以这个问题能在JSI上彻底解决。
下面的例子，我们将在同一个页面上同时使用Scriptaculous和 jQuery 类库。证实一下JSI隔离冲突功能。
示例页面（hello-jquery-aculo.html）：
xml 代码
<html>
<head>
...
何谓安需装载？
脚本程序一般都是下载后执行 ，当脚本库非常庞大时，一次性下载起来非常费时，传统的解决方式是，按功能模块把脚本写在不同的文件中，页面上手动加入script标签装载指定内容，但 是这有一些缺点，类库的使用者需要知道没个脚本之间的关系，顺序要求等等，而不可能要求每个类库使用者都对其非常熟悉，出错的可能性很大。于是很多框架开 始支持导入指令，想使用什么一个导入函数就完了，不必一堆堆的script文件，不用小心翼翼的关注着他们的依赖关系。
安需装载可分如下三种模式：
即时同步按需装载（阻塞，JSI、JSVM、dojo）。
最简单的按需装载实现 ...
jindw
- 浏览: 203629 次
- 性别:
- 来自: 初到北京
- 详细资料
搜索本博客
最新评论
-
JSI 类库文件格式探讨
应该是jsa啥时候有新版本
-- by dingyuan -
JSI 类库文件格式探讨
jsi啥时候放新版本啊
-- by dingyuan -
最近工作上比较郁闷
一个人犯错误不要紧，总要得是能从错误中吸取教训，并且不要再犯第二次。我觉得不应该 ...
-- by twfx -
2008年我可以做一些什么
呵呵，开始了一些，完成了一些，黄掉了一些。
-- by jindw -
2008年我可以做一些什么
你的计划开始了吗？
-- by programmer
评论排行榜