|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
时间：2008-03-10 关键字: json javascript
一直没时间玩js，看到douban网的开放api后，查了些文档，了解了一下 jsonp 跨域请求方式.跟大家分享一下。
其实 jsonp 是个很简单的一个东西。 主要是利用了 <script/> 标签对 javascript 文档的动态解析来实现。（其实也可以用eval函数）
来个超简单的例子： 首先是准备客户端的代码，
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Test Jsonp</title>
<script type="text/javascript">
function jsonpCallback(result)
{
alert(result.msg);
}
</script>
<script type="text/javascript" src="http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback"></script>
</head>
<body>
</body>
</html>
其中 jsonCallback 是客户端注册的，获取跨域服务器上的json数据后，回调的函数。 http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback 这个 url 是跨域服务器取 json 数据的接口，参数为回调函数的名字，返回的格式为
jsonpCallback({msg:'this is json data'})
Jsonp原理： 首先在客户端注册一个callback, 然后把callback的名字传给服务器。
此时，服务器先生成 json 数据。 然后以 javascript 语法的方式，生成一个function , function 名字就是传递上来的参数 jsonp.
最后将 json 数据直接以入参的方式，放置到 function 中，这样就生成了一段 js 语法的文档，返回给客户端。
客户端浏览器，解析script标签，并执行返回的 javascript 文档，此时数据作为参数，传入到了客户端预先定义好的 callback 函数里.（动态执行回调函数）
声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
时间：2008-03-11
这样跟server端还是耦合过高了，而且如果如果我是在一个类的内部加载并注册的callback，这时的context this就很难传递了，难道在类的内部还需要知道创建本类的实例名？
|
| 返回顶楼 |
请登录后投票
|
|
时间：2008-03-11
服务器回调也就是这样了。而且这并不能说是耦合高。因为指令都是客户端发起的，服务器端并不了解客户端怎么调用（名字只是一个钩子，对服务器来说没有什么特别意义）。山人说的context this问题偶不太理解，这个问题不是所有closure都有的吗，这里有什么特别影响么？
|
| 返回顶楼 |
请登录后投票
|
|
时间：2008-03-11
假如我在类的内部调用获取json数据,我希望在数据加载后自动调用本实例的另一个方法,这时用的回调是不是就必须知道本实例的变量名了?如果单个还好,在全局范围订阅一个通知,通过callback分发,这时用closure是可以保留this的context,如果同时有多个同样的操作呢?再加时间截或者uniqueID标识?不知道是不是有更好的办法
另外推荐一下emu的这种方法: http://www.blogjava.net/emu/articles/129240.html 不过我测试发现只有ie和opera支持,firefox和safari没效果,如果能兼容,这个方法才比较有吸引力 |
| 返回顶楼 |
请登录后投票
|
|
时间：2008-03-11
emu的方法我看了，虽然也是一个法子，但是代价和收益相比，我觉得真的没啥特别好的地方。
首先，他隐含了个条件（或者说这句“想要用一致的callback接口来回传数据”稍稍说到了一点）文章里没说，就是服务器的输出，实际上是带有callback名字的，他的例子里是visitCountCallBack。 这说明两点： 第一：服务器输出的不是真正的json。 第二：仍然是耦合。只不过现在client code看不到这个耦合，而是library和server代码的隐藏耦合。对于同时包含两端的框架来说，这也许ok，但是我很不喜欢这种隐匿式的耦合。 这两点比之xxx?callback=myCallback，毛病大许多。 第一条就是强制了callback接口，你爽了，别人（别的调用者）都不爽。 第二条就是对耦合的认识，我认为是有失偏颇的。 BTW，documentFragment来得到一个单独的script作用域，我担心会有内存泄漏，可能应该多多测试看看。 |
| 返回顶楼 |
请登录后投票
|
|
时间：2008-03-11
还有，emu的方法的原理应该是跨浏览器通用的。如果不生效，大概是代码有些小瑕疵。
山人讲的其他问题，我理解是这样的： 1. 我不想调一个全局函数，我想调一个局部函数，或者方法，总之那才是我的逻辑。 2. 我可能出于某种原因要同时发起若干个回调。 这种需求我觉得确实需要对callback上做包装。 |
| 返回顶楼 |
请登录后投票
|
|
时间：2008-03-11
当然，由于现有条件就是这样，我说emu方案的那两点，在其他方案里也是存在的。比如只要你用script回调，那总不可能是纯的json。
问题是，emu同学花了那么多力气，其实绕了一圈也没有能提供更好的方案。因为所做的，不过是对最终编程者隐藏掉callback名字而已。这种活，不用iframe技巧，其实一样可以达到的。 |
| 返回顶楼 |
请登录后投票
|
|
时间：2008-03-11
我可以贡献一个最土的思路，就是为每一次回调自动产生一个独立的名字。
比如第一次回调就是xxx?_callback1 第二次就是xxx?_callback2 当然这个过程是被包装起来自动的，最终程序员不用管它。 有人说全局命名污染，这个是没错。但是问题其实没那么严重，大不了你产生一个GUID好了，再有冲突，宇宙都毁灭几次了。 这样的唯一问题是它不是静态化的。 要静态化，其实就是避免不了对callback名字的约定。那么我们就污染吧，反正就污染一个，比如叫他 _九天十地菩萨摇头怕怕劈雳金光雷电掌_json_callback。当然考虑到每次都要写，我建议还是搞短点，例如 JSON.CB JSON.CB完全可以鉴别自己是在哪个script里被调用的（具体方法就省略了），所以你在生成script时，插点草标就可以了。 iframe在这里唯一的好处就是连这个小小污染都没有了。不过考虑是否值得呢？这就贱人贱智啦！ |
| 返回顶楼 |
请登录后投票
|
|
时间：2008-03-12
原来firefox需要用绝对地址才可以,safari需要往iframe write html才行,我做了个简单的demo,唯一的一个约定就是输出的json文件的格式是var json = {...}; loadjson.html(没有写兼容safari的方式) <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="zh-CN">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
<meta http-equiv="Content-Language" content="zh-CN" />
<meta content="all" name="robots" />
<title>json数据加载演示</title>
<script type="text/javascript">
function $loadJSON(url, callback, context){
var iframe = document.createElement("iframe");
iframe.style.display = "none";
iframe.src ='javascript:\'<script src="' + url + '" type="text/javascript"><\/script><script type="text/javascript">frameElement.callback(this.json);<\/script>\'';
document.body.appendChild(iframe);
iframe.callback = function(json){
callback.call(context || window, json);
iframe.src = '';
iframe.parentNode.removeChild(iframe);
iframe.callback = null;
iframe = null;
};
}
function Demo(url){
this.url = url;
this.element = document.createElement('div');
document.body.appendChild(this.element);
this.bindData = function(json){
this.element.innerHTML = '本次取回的数据：' + (json ? json.number : '(网络错误)');
}
$loadJSON(this.url, this.bindData, this);
}
</script>
</head>
<body>
<button onclick="new Demo('http://wfsr.net/temp/json' + ((Math.random() * 100 | 0) % 2 ? '' : Math.random()) + '.js')">加载</button>
</body>
</html>
json.js var json = {"number" : Math.random() * 100};
|
| 返回顶楼 |
请登录后投票
|
|
时间：2008-03-13
我给emu的留言：
我的意思是，无论你用iframe或是只能用于ie的documentFragment（这明显是ie的一个问题，凭什么要为任意一个新节点产生一个新的脚本scope？而且我怀疑这会引起内存泄漏——ms的人在说memory leak的patterns那个文章里曾经提到过由这一问题引起的内存泄漏），所付出的代价似乎比不上得到的好处。 因为不用iframe，你也可以达到向最终编程者隐藏callback名字的目标，只需要callback是由你的框架托管和包装起来就可以了。差别只在于，这种方式，这个callback名字会污染当前的global上的命名空间，iframe则不会，因为它在一个独立的scope里——但是付出的代价是有独立的browserContext（包括window、document等对象）。 因此，iframe只是一个锦上添花的工具。我认为理想的目标是： 1. callback名字最好是可配置的。因为万一有些人写死了callback名字。。。 2. 有些人不仅写死了，而且不是callback({...json...})，而是var hardCodeJSON = {...json...}，最好也能处理这种情况（肯定是可以做到的）。 3. 不能每次都搞一个iframe，这样太浪费。iframe的唯一目的其实是搞一个独立的scope，所以弄一个iframe就可以了。还有基于前面提到的因素，建议不要用documentFragment。 那么在一个iframe情况下，你说的“多个一模一样的callback”的冲突还是存在。这就需要用其他技巧解决。所以反过来，如果其他技巧解决了这个问题，那么iframe的唯一好处就是一丁点都不污染全局命名空间——个人来讲，我认为这个好处还是相当有限的。 下面说一个一般化（也就是不需要iframe）的最土的思路。原本我们插入一个<script>标签来读取json。现在我们可以插入3个 <script>。第一个做初始化，建立服务器所需要的callback函数，如果有命名冲突，则把之前的那个变量保存起来。第二个还是 load JSON。第三个做清理，去掉服务器所用的callback，并把之前的变量恢复起来。 当然这只是一个一般的描述，实际做的时候，肯定有很多问题要解决，但是从大体上看，应该是行得通的。 |
| 返回顶楼 |
请登录后投票
|
