这个问题是关于骨干0.9.2的。
自从升级到骨干0.9.10之后,我们选择了重写Backbone.sync,它的工作原理就像一个魅力.
(很抱歉读得太长了)
我正在修改Backbone.wrapError函数,我被一行代码搞糊涂了。我知道这句话的作用,但不知道为什么它是必要的。
resp = model === originalModel ? resp : model;我很好地掌握了Backbone.wrapError的功能、返回的内容以及它是如何使用的,但我似乎无法理解上面这一行的目的。
主干的文档指出,wrapError将“用回退错误事件包装可选的错误回调”,这是正确的。此外,我还了解到,在库中从提取、保存、销毁和重置函数中调用Backbone.wrapError 4次,以确保库不会忽略AJAX错误。例如,如果一个AJAX错误回调被传递到fetch方法中,那么它将与传递的几个参数一起执行,如果没有,模型将触发一个错误事件,其传递的参数也相同。
样例呼叫:
options.error = Backbone.wrapError(options.error, model, options);Backbone.wrapError:
Backbone.wrapError = function(onError, originalModel, options) {
return function(model, resp) {
resp = model === originalModel ? resp : model;
if (onError) {
onError(originalModel, resp, options);
} else {
originalModel.trigger('error', originalModel, resp, options);
}
};
};这一行(resp = model === originalModel ? resp : model;)出现的问题是,模型和resp对应jQuery/Zepto错误回调参数列表中的前2个参数。我遇到的第一个问题是如何命名这些参数(模型、响应),因为在调试时,我已经看到这两个参数是jqXHR/xhr和textStatus/errorType。textStatus/errorType参数通常是"error“,但是(根据docs)也可以是”超时值“”解析错误“等等。对model === originalModel的比较对我来说毫无意义。对XHR对象和Backbone.Model实例进行硬比较总是失败的,model将被存储到response (resp)中,这很好,因为model实际上是XHR响应对象.对我来说,这一行似乎毫无意义,但我继续把它包括在我修改过的wrapError方法中。
因为model === originalModel总是计算为false,所以该行似乎是resp =model的详细版本;这是无用的,因为您可以完全删除行,而model参数可以传递给originalModel.trigger('error', originalModel, resp, options);而不是resp。
model === originalModel 是否有可以计算为真的实例?
任何人有更多的Backbone.js经验,AJAX有一个答案/解释为什么这一行是必要的?
发布于 2012-09-13 19:51:23
TLDR/悬崖:
下面这一行奇怪的代码用于确定错误回调是从模型级别的失败验证中触发的,还是从提取、保存或销毁方法(全部调用Backbone.sync)失败的AJAX调用中触发的。如果失败来自验证,则不会更改resp变量,因为resp应该已经保存了验证返回的有用信息(例如错误数组或关于错误的字符串)。如果故障来自糟糕的AJAX请求,则将XHR对象存储到resp中,因为XHR是可用的信息最多的项。不幸的是,XHR被传递到这个函数中,因为模型和主干文档没有指出这个参数并不总是表示模型。Resp用于保存有关错误的有用响应信息,并发送到错误回调或抛出的错误事件。
好吧。我学到了一些关于这条奇怪的台词的东西。
resp = model === originalModel ? resp : model;在主干中存在AJAX错误和验证错误。方便地,主干将两个错误放入同一个函数-- AJAX错误回调。问题是传递给这些函数的参数是不一致的。当有AJAX错误时,XHR对象是可用的,但在验证错误期间则不可用。
在一个成功的AJAX请求之后,您的JSON数据可以选择地通过模型的验证函数传递。在主干中,验证函数should return false or nothing at all when there are no errors。当出现错误时,通常会返回一个数组,比如从model!中返回的任何东西(通常是一个错误消息数组)作为resp参数传递给“包装”错误回调,模型本身作为传递给。
_validate函数有点草率,有多条返回语句,但当验证失败时,将命中第9行。_validate函数的第9行传递this (模型)、error (从模型验证方法返回)、options (ajax选项、成功、错误、超时等)。这与xhr (xmlhttprequest对象)、errorType (“错误”超时、“解析错误”等)、options (ajax选项)中传递的AJAX错误不同。
validate error: error(model, validate_return_value, options)
ajax error: error(xhr, errorType, options)
1 _validate: function(attrs, options) {
2 if (options.silent || !this.validate) return true;
3 attrs = _.extend({}, this.attributes, attrs);
4 var error = this.validate(attrs, options);
5 if (!error) return true;
6 if (options && options.error) {
7* options.error(this, error, options);
8 } else {
9 this.trigger('error', this, error, options);
10 }
11 return false;
12 }上面奇怪的代码行是必要的,因为这一个函数处理来自两个不同方法的错误。AJAX和验证。这2向它发送不同的参数,因此这意味着规范它们并使用一致的参数列表抛出事件。
When a validation error occurs, the model does not change,因此传递给错误回调的与originalModel完全相等。resp参数的目的是保存有关错误本身的信息。当出现AJAX错误时,“超时值”、“解析错误”或“错误”都不能像XHR对象那样提供信息。
这个奇怪的小行决定了错误回调是否是从_validate 访问的,或者通过普通的AJAX错误(例如404. )访问的,当从value访问它时,resp是从value返回的值。它应该是信息丰富的,并为前端模板显示有用的数据。当产生的错误来自HTTP错误时,有关该错误的最有用信息是XHR对象,该对象作为模型参数传递到此函数中。
一种有望简化的wrapError和验证函数的方法
Backbone.wrapError = function(ajax_error_callback, model_or_xhr, ajax_options) {
return function(model_or_xhr, error_info) {
if there was an ajax error, error_info = the xhr object
if there was a validation error, error_info = whatever was returned from validate
if there's an error callback {
run the error callback with (the original model, error_info, ajax_options) as parameters
if there is not an error callback
throw an event called 'error' with (the original model, error_info, ajax_options) as parameters
}
};
};原件:
Backbone.wrapError = function(onError, originalModel, options) {
return function(model, resp) {
resp = model === originalModel ? resp : model;
if (onError) {
* onError(originalModel, resp, options);
} else {
originalModel.trigger('error', originalModel, resp, options);
}
};
};*显示从这里调用的错误回调
https://stackoverflow.com/questions/12395699
复制相似问题