2008-04-21

Ext 2.1 的 Full REST support 是不是就是一个噱头啊??

我看一下2.1的代码
他所谓的对rest的支持只是对 form.action做了一些小小的改动

大家可以自己和2.02的对比一下
而且这个改动实际上可以理解为是对 2.02的一个缺陷的修复(2.02里form的ajax提交不能设定header信息)
我是怎么的也没看出来2.1对Full REST support 做了哪些特别的工作

有分析的更透彻的吗? 给大家讲一下 2.1到底是怎么提供的Full REST support呗

谢谢了
评论
clia 2008-05-07
fangzhouxing 写道
引用
至少在Ext 2.0.2的代码里是找不到PUT和DELETE的方法的，如果要做这两种操作的话，还需要手工来设定HTTP Method。2.1里加入了原生的支持，方便了一些，至少操作上要爽了一些。


请问“加入了原生的支持”是什么意思? 先谢了。

是指对PUT和DELETE的原生支持。还没去考察dlee说的那六点，但至少方法上已经够用了，如果能有缓存和身份认证的支持，那就更爽了！谁知道有没有？
fangzhouxing 2008-05-07
引用
至少在Ext 2.0.2的代码里是找不到PUT和DELETE的方法的，如果要做这两种操作的话，还需要手工来设定HTTP Method。2.1里加入了原生的支持，方便了一些，至少操作上要爽了一些。


请问“加入了原生的支持”是什么意思? 先谢了。
clia 2008-05-06
至少在Ext 2.0.2的代码里是找不到PUT和DELETE的方法的，如果要做这两种操作的话，还需要手工来设定HTTP Method。2.1里加入了原生的支持，方便了一些，至少操作上要爽了一些。加这些东西可能本来就不需要多少代码就能完成的，只是以后大家都有REST的概念了，更有利于基于REST的开发。
fins 2008-04-27
4. 支持HTTP客户端缓存。

这个是指什么呢?缓存什么数据?

另外 我觉得,任何一个现有的XHR框架(工具代码),如果要支持上述6点(除了第4点),都不是什么困难的事情吧? 不知道我的理解对不对

从对ext的对比来看, 2.1针对rest所做的事情牵涉到的代码实在是太少了, 可以说,在2.02的基础上稍微修改了一点点,然后就自称full rest support了.
dlee 2008-04-27
REST其实跟客户端和服务器都有关系。目前对REST支持最好的服务器端框架是Ruby on Rails，ActiveResource是Rails的REST客户端库。Rails + ActiveResource是目前最好的REST技术实现。

7thbyte说支持HTTP就是支持REST，这个观点是错误的。REST是一种架构风格，HTTP只是一种技术。虽然HTTP就是设计用来实现REST架构的，但是也可以用HTTP实现其他的架构风格，例如RPC，SOAP就是RPC风格的。

全面支持REST说的是什么意思呢？
1. 完全支持HTTP的7种method：GET/POST/PUT/DELETE/HEAD/OPTION/TRACE，至少支持前面4种。
现在绝大多数Ajax框架例如Prototype/Dojo都只支持GET/POST。而XMLHttpRequest对象是支持所有method的，并不是XMLHttpRequest对象的问题。
2. 可以设置任意的HTTP header。
3. 可以得到HTTP响应中的status code和HTTP header。
4. 支持HTTP客户端缓存。
5. 支持HTTP身份认证，包括Basic和Digest两种。
6. 提供了方便的API接口，使得开发者可以以最方便的方式（例如，以最习惯的面向对象编程方式）来操作服务器端的资源。

我对Ext JS不熟悉，大家对照这个标准看看，Ext JS是不是全面支持REST。
vicksong 2008-04-23
我日,果然不出所料,今天测试了一个,2.1的EXT跟2.02的EXT就不向下兼容,看样子,不可能指望EXT3.0跟2.X有什么兼容性了,现在开发好的程序,如果以后想换成3.0EXT,又要重新开发,太累了......
7thbyte 2008-04-22
REST就是很单纯的HTTP

支持HTTP就是支持REST

一直不明白full support是什么意思？
REST还需要什么特别的东西吗？
fins 2008-04-22
还是没太明白

2.02在处理rest的时候有什么问题?
2.1是如何解决的呢?
我看了ajax和 form相关代码 ,修改量很小 只是改动了几行代码而已

分析不出来ext 2.1 针对 rest提供了哪些本质上的改进
sp42 2008-04-22
2.1之前的Ext对rest相对比较有限的，官方wiki上《RESTful Web Services 4 Ext》透露：
引用
假设用户在浏览器地址栏输入/api/users将会得到401 Authorization Required的回应，显示登录的对话框并缓存结果，需要再次输入信息。感谢的是，XmlHttpRequst的设计者已经想到过这个问题，在请求的参数上加两个可选的参数，指定用户名称密码（亦进行base64的编码），不过遗憾的是，当前标准的ExtJs Ajax调用并不支持这两个可选的参数。直到有解决方案出现之前（我想这需要一点时间）你有这些可选方案：

* 1 在一些浏览器上在url后面加上用户名/密码：注意一些浏览器不支持（包括IE6以后的版本）；
* 2 借助Doug Hendricks优秀的ext-baseX.js库；
* 3 返回一个非标准的HTTP状态代码，而不是401Authorization Required这样浏览器就不会提示，例如你可返回403Forbidden典型把这个403的代码涉及到HTTP/101标准，的内容即是Authorization不会帮助而且不应重复要求，但是你会打算取巧地使用这种方法（不足的是使用其他的Web Service会有所限制）

http://extjs.com/learn/Manual:RESTful_Web_Services_(Chinese)]
fins 2008-04-22
代码在 form/action.js 里

不过看了也是失望 绝对是噱头

其实 只要支持ajax 支持自定义request header信息,支持自定义method
怎么可能支持不了rest呢?

也就是说, 其实 任何一个相对完善的ajax框架 都支持rest.

我个人认为拿rest来做幌子 纯属噱头

不知道其他ext达人没有啥见解没
lonelyblue 2008-04-21
changes.html里：
“Adapters: Changes to provide full REST support ”

看了ext-base.js 的源代码 也没发觉有哪些地方支持的。。。。。。。
xyz20003 2008-04-21
可惜国内法律不健全，上诉一次估计要3年5载才能有结果，要不也可以跟jack商量好，咱们偷偷收集盗版使用的情况，告赢了分咱们一成啥的。

改协议其实也没什么大问题，继续用ext-2.0.2不就好了么？

对我们更有巨大意义，这下子没人过来指着鼻子骂我们“用别人免费的东西赚钱”了吧？
就是不知道gpl协议是不是也会强制把相关教程也开源，如果那样我们就要专门做一份2.1的教程了。呵呵~要是真这样就搞笑了，岂不是看了我们教程的人就要把自己所有的代码都公开？估计gpl影响不到电子文档和出版物。
i_love_sc 2008-04-21
已经不用ext了。现在使用yui。发现yui的优点很多。比如dom简洁，比如考虑的细致。但是比起ext来的话，缺点也有很多。比如结构化不如ext，比如控件不如ext多。
fins 2008-04-21
因为中国绝大多数使用ext的人都是偷着用
也就是说 用在商业上 但是也不给钱
中国的开源市场就是这样 没办法

ext改协议怎样? vista售价4位数怎样? photoshop上万元又怎样?
lonelyblue 2008-04-21
关于授权由原来的LGPL，修改为现在的GPL怎么大家都无动于衷？
fins 2008-04-21
顺便说一句
2.1的变化不是很大
新特性有限,而且有一些bug
当然看了一下代码 2.1修复的一些bug还是很重要的
(不过之前分析的事件销毁机制的bug没有修复,估计那个要修复动作比较大吧 所以要在以后修正)

总之. 我觉得如果不是着急使用新特性, 同时没有被2.02的某些不可忍受的bug折磨的话 还是先不要升级了

也许2.11 2.12 2.15 ... 倒是可以一试.
不过这个2.1 还是再等等吧 bug还是有很多的.
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

fins
  • 浏览: 706275 次
  • 性别: Icon_minigender_1
  • 来自: 小胖儿的大城
  • 详细资料
搜索本博客
我的相册
D491c37e-81de-385c-ad95-b7a20ad6a3c8-thumb
David Recordon
共 63 张
其他分类
存档
最新评论