JSPackager－－－ 一个开放、无侵入的脚本管理框架

简介

JSPackager项目旨在提供一个开放的、无侵入的脚本库管理解决方案，让类库编写者可以以简洁的程序语言描述好自己编写的类库的相关依赖，让最终用户从繁琐的依赖管理中解脱出来，使类库使用起来更加简洁方便 。此外，我们还提供了一种对象有效域的封装机制，方便于 重用、组织第三方脚本，避免它们带来的命名污染问题。

同时框架尽量做到简洁，不加入特殊语法，也没有太多基础类库，被管理的脚本无框架依赖。

JSPackager作为一个开放的整合已有类库的框架，不打算提供过多的实用 API ，而是让最终用户根据自己喜好整合其他类库，当能我们也会提供一些整合已有著名脚本类库的实例（如：Prototype、Scriptaculous、YAHOO UI）。

具体功能有：

1.给普通javascript脚本加入包概念，通过包结构组织脚本。
2.提供一种引入、重用、封装 多方javascript脚本的解决方案。
3.统一管理脚本依赖，直接使用什么就导入什么，不用理会间接的依赖关系，把程序员从冗余的依赖管理中解脱出来。
4.解决多方脚本的命名冲突问题，多版本共用问题。
5.解决重复加载问题，想用什么就导入什么，不用担心重复的导入语句。


代码体验：

<!-- 引导脚本 -->
<script src="../scripts/startup.js"></script>
<!-- 页面脚本 -->
<script>
$import('com.yourcompany.*');;
$import('com.mycompany.MyClass');;
$import('com.mycompany.myFunction');; 

var yc = new YouClass();;
var mc = new MyClass();;
yc.doSomething();;
mc.doSomething();;
myFunction();;
</script>

目前该类库最新版本是 1.1Alpha3 ，基于LGPL开源协议。

更多更新信息请登录如下网站：
http://www.opencode.cn/jspackager(国内)
http://jspackager.sourceforge.net（境外）

jsvm：
jsvm是一个功能非常强大的脚本框架，但是实现也相应复杂，它甚至提供多种自己的中间编程语言，相比之下jspkg是一个简单的框架，没有特别的语法，不需要程序员学习过多的东西。
dojo：
dojo有一个完整的模块导入解决方案。也可以支持jspkg中类似的运行事依赖和装载器依赖。而且功能丰富，有较多基础类库可用。
相比之下，jspackager是一个开放的管理框架（jspkg可以管理已有第三方脚本，脚本对管理框架是无依赖的），dojo不是如此，而且侵入比较严重。
细看dojo的包加载方案实现，先创建包对象（一个简单的Object实例，dojo为默认）；使用XMLHttp加载脚本，使用js的eval函数，运行之；相当于修改了这个包对象，将新的属性、函数、添加上去。
所以，从代码上就可以看到，dojo的包在代码中有直接的反映（这样不利于重构），以后的引用也是直接使用包全名，所以，dojo的导入称为require 而不是jspkg的$import。
总结：dojo是一个功能比较完善的类库，而jspackager是一个开放的脚本管理框架，本身不提供丰富的基础类库，但是它可以重用第三方实现来弥补这一不足。

看了一下, 觉得还是不错的, 尤其是"接口包与包实现", "模拟出的保护域" 等特点.

目前各种 javascript 框架在一起使用时有一个主要问题就是各成体系, 合在一起使用难免成为大杂汇(比如包管理方式就很不统一, 如果同时使用代码很难看, 还可能会产生冲突), 不合在一起吧, 每个框架又总有一些地方不够方便, 难以取舍;

不知道楼主对将 jspackager 和 dojo 这类本身就有比较完整的package的框架的集成有什么建议? Prototype、Scriptaculous 等的集成可能比较容易一点,因为它们是相对独立的代码.

我目前没有打算做对dojo这种复杂类库的支持（我崇尚简单），将把精力放到基于JSPackager的脚本类库的API 文档编译工具（类似jsdoc）的和脚本编辑插件上。

基于dojo的脚本对框架本省依赖严重，我想纵使要集成它，可能也要对其脚本做些修改，这将使得事情更加复杂，还不如直接使用dojo，dojo和jspackager都没有占用什么全局变量，我猜测，它们应该可以共存。

alpha3提供了对YAHOO UI的支持，YAHOO UI也有包结构，只是没有依赖管理，我想dojo使用类似的方法应该也可以实现。

我主要是关心一起使用的时候能不能统一用一种 import 的方式, 不然会觉得很乱, dojo 的要使用 dojo.require("..."), JSPackager 却又使用 $import("...")

有个问题，有了JSVM为何还要弄个JSPackager？

与JSVM相比JSPackager是个简单的框架，我倾向于页面简单化，估计你也不想开着火车逛街吧？

无侵入、简单 就是JSPackager的优势

无侵入：JSVM也集成了YAHOO UI。我们以它为例（虽然我并不欣赏这套类库）：
[list]jsvm中，yahoo ui原有的脚本程序都修改了很多，我想，这样一来 YAHOO UI 的每次升级，都够jsvm开发人员忙活的吧。[/list:u]
[list]JSPackager中，我没有对 YAHOO UI 原脚本做任何修改，只是把它的脚本放到一个目录中（包路径），编写了一个包描述文件（说明那些脚本又那些对象，那些脚本依赖于那个脚本）。结束了，而且以后升级的时候，如果没有功能的添加，把新的脚本覆盖上去就差不多了。[/list:u]

简单：
[list]JSPackager管理的脚本对框架没有什么依赖，这不但有利于将第三方脚本集成进来，也有利于以后将基于JSPackager编写的脚本分离出去（也许某些简单的场合，你根本不想使用任何框架）。这时，你只要把原来的$import("...")换成对应脚本及其依赖的<script>标记即是。[/list:u]


JSVM自身功能强大，而我们并不打算做这些重复的轮子，我们可以通过集成/封装第三方库来增强自己。海纳百川，有容乃大。

我更喜欢骑自行车逛街。。。

试了一下，JSPackager的YUI DEMO都报Script Error的说

是有些例子引用的引导脚本错了，应用到根目录上的一个版本，例子的错误，不是框架的错误。马上改正。

感谢提醒！

从yahoo ui的例子改写的时候，没有注意他的例子不在同一个目录层次。
那些出错的地方

<script type="text/javascript" src="../../../../scripts/startup.js" ></script>

改成

<script type="text/javascript" src="../../../scripts/startup.js" ></script>

就是了。
这个错误如果部署在tomcat根目录上，在ff上还测不出来。