基于AJAX的Web框架

AJAX框架，故名思义，是让AJAX方式的Web开发变得更容易的框架。
而基于AJAX的Web框架，是通过AJAX方式，让Web开发变得更容易的框架。

传统的Web MVC框架是以服务器为中心的，MVC都放在后台控制。

AJAX火了之后，大量的客户端引擎与组件的出现，为我们提供了另一种思路。
只把Model放在服务器端，以Servie的形式暴露出来。
将View与Control放在客户端做。

Swato是对于这个思路进行探索的框架。
在框架的帮助下，做View和Control所需要的代码可以大幅减少，开发轻便了不少。但是仍存在着不少尚未解决的问题。

现在，Swato已经发布了Beta版，并且提供了一个Online Demo.
http://swato.throughworks.com/

欢迎提宝贵意见，有兴趣的同志欢迎一起来参与开发。

非常赞同您的设计理念，只是有一点疑惑，这种框架不是已经有了吗？像DWR
希望您能谈谈相较于DWR，Swato的设计有哪些什么突破性？

呵呵，还有，支持国产，最近在用DWR做开发，如果好的话，我就改用你们的了

这个Auto Suggest 有水分. 不能和google相比.
因为国家都是固定的,把所有国家返回到客户端.
只是那个下拉框才是ajax. 其他的没看.

另外这代码东抄西搬的,会把人搞晕的.

基本是抄袭了 json.  
http://oss.metaparadigm.com/jsonrpc
看看web.xml,让我没兴趣了.
https://swato.dev.java.net/doc/pdf/swato_reference.pdf

应用了prototype
swato.js 还有 // Based on code from http://getahead.ltd.uk/dwr
小心开源协议啊! 另外logger,floatWin等.


你们什么组织啊?

throughworks
怎么和这个公司联系起来了？里面可都是牛人呀

当前在以Java为后台的AJAX框架中，
比较有名两个是JSON-RPC-Java 和DWR。

Swato与他们的共同之处是实现了JavaScript与Java
对象间的数据转换与远程方法调用。从各自提供的unitTest Demo可以
看到这一实现的支持能力基本是相同的。

各自的差异主要在以下几个方面。
1.为开发人员开发前台JavaScript提供的支持。
   由于采用AJAX框架后，很多View和Control的代码需要转移到前台用JavaScript实现。然而JavaScript的编程毕竟是比较痛苦的。
   在JSON-RPC-Java中，从服务器返回到前台的虽然是JSON--JavaScript对象，但是他没有提供组件帮助开发人员处理这些对象。
   对于返回XML的框架，一句一句书写DOM层次访问是比较痛苦的。
   而对于HTML DOM的操作，也是比较痛苦的，所以所以DWR提供了一系列DWRUtils来帮你减轻这一部分工作。但是对于一些需要更加灵活的View处理，利用DWRUtils仍然感觉不够用。
   在Swato中，客户端接受的数据可以是JSON(Swato的后台是直接把Java对象映射成JSON)，也可以是XML(你可以从远端URL中获取XML, 它在Swato客户端引擎中被转化为JSON，参见RSS Reader的例子)。所以对于开发人员来说，它在客户端所要关心的只是JavaScript对象。(结构与Java对象或XML结构对应)。然后利用Swato提供的一些View组件(AutoSuggest, Select, Form)进行渲染。对于自定义性比较强的View控件，你可以在前端使用Template引擎 （来自TrimPath,类似于Velocity的简单语法）。甚至可以把它封装成你自己的组件，只要在其中实现gotResult与gotError函数，便可以很轻松的与Swato远程调用功能集成。参见(CRUD例子中的代码。)
    Swato力图在客户端为开发人员减轻JavaScript代码的编码量，其实Swato的unitTest例子来自于DWR。 类似的测试功能，在逻辑控制上，DWR用了几百行的JavaScript而在Swato上只需要几十行。
    不管用哪一个框架，由于JavaScript缺乏强大的编辑器和调试器，所以开发起来还是比较麻烦，对此，Swato在前台集成了fvlogger, 相当于Java方面的Log4j，为Js的开发带来更大便利。

2.后台服务的注册与访问控制方式。
    在后台服务的注册方式上，JSON-RPC-Java默认的是在Session中的Bridge里注册要使用的Java对象。这种方式有很多的限制，比如使用的时候需要JSP或者Servlet程序中来进行注册。形式不够灵活，服务的周期管理也比较麻烦。这是
JSON-RPC-Java被批评的重点。
    DWR有了很大的进步，它用dwr.xml将你需要暴露的服务明确地定义在其中，在前台的JavaScript中，用<script src="xxx">的方式既可以把服务引进到客户端来。周期管理也在XML可以配置。
    而在Swato中，后台服务的暴露方式通过filter来实现，前台的调用利用一个
ID值来寻访后台服务类。Swato提供了一个Spring的默认服务Loader，在Spring配置的bean ID直接可以被前台所访问到。如果你不想采用Spring,只需要替换一下filter，以你自己的方式来进行服务的暴露和权限控制。后台对象的生命周期方面，Swato采用的是request对象注入式，把你的服务对象中实现RequestAware接口，这个服务相关的生命周期便可由你灵活的进行处理。

是throughworks，不是thoughtworks

错误错误. DWR是javascript对象.非xml.
DWRUtils不是做dom层次访问.而他做的有些和prototype.js重复.
怀疑swato.js 还有 // Based on code from http://getahead.ltd.uk/dwr 是不是你写的.

swato中用了来自其他项目的库，但都是开源的项目。source来源与license都保留于代码中,没有修改。一些方法级别的代码如果来自于其他框架。会明确标出从哪里来的。大名鼎鼎的protoType中不也能看到这样的说明吗。

而与JSON-RPC-Java，在对象转化与远程调用的思路基本上是一致的。
但是在具体的实现手段上，因为有些不同的看法，与JSON-RPC-Java的作者通信讨论过几遍。发现双方有一些侧重点不一样的，没能购达成一致一起来做。
所以对于这个框架参考了一些思路，实现方面基本上是从头做起的。如果看双方的代码，不管客户端还是服务器端，差别还是不小的。

而对于文档现在没有及时更新到与最新的版本对应，因为完全由业余时间来做，不能及时得到更新，很不好意思。

我们不是一个坏组织----谁好抄谁，光环戴在自己头上。
每个东西都有它好与不足的地方，我们想从方便开发者的角度，能把好的东西聚集起来，不好的自己想办法补一补，整合起来，最后让大家用得方便，如此而已。

刚做OpenSource不久，如果License方面有什么问题的话，希望得到大家具体的建议。

Sorry，发布了些错误的信息。你说得对，谢谢你的批评：）

更正 ->
对于返回XML的框架，一句一句书写DOM层次访问是比较痛苦的。
对于HTML DOM的操作，也是比较痛苦的，所以所以DWR提供了一系列DWRUtils来帮你减轻这一部分工作。

swato.js中的util部分借用了DWRUtils的代码。
其他的部分也只是对prototype进一步封装，这个确实是我一句一句写的。
边做边学学prototype：）.