包含
>将url的动作的url注入到ajax调用中最好的方式是什么？
>选择JsonBehavior时有什么考虑？
>在服务器端处理错误的最好办法是什么？
>客户端error()回调应该由任何错误(即意外的OutOfMemoryException)触发,还是只能通过可预见的错误(即无效输入)触发？
>以触发error()回调的方式导出错误的最佳方式是什么？
>确保错误回调的最佳方法获得正确的状态代码和响应文本.
>验证错误会导致ErrorCodeCode错误,或者它们应该是响应验证对象的一部分.
>客户端处理错误的最佳方式是什么？
>应该以与验证摘要相似的方式显示服务器端意外错误？也许是一个刚刚出现的错误对话？客户应该能够区分两者吗？
别人有什么强烈的意见？
解决方法
将URL的操作的URL注入到Ajax调用中的最佳方式是什么？
没有关于这个的约定,它也在很大程度上取决于你的内容如何被带到客户端.是通过视图/部分视图(在这种情况下,您可以使用Html / Url帮助方法生成URL,或者它是纯粹在客户端生成的(模板等).很常见的是,我们只是希望通过Ajax扩展一些常见的HTML元素行为(如表单,按钮和链接)在这种情况下,最好提供正确的URL,我们也可以从他们那里读取,并在脚本中使用它们(如链接中的href),用户指向的位置也更清楚无论我们将它们转换为GET / POST / DELETE / PUT请求都不重要,我建议避免在脚本中使用硬编码URL,因为您可能会更改路由或提供其他处理方式.使用Html帮助在维护方面,尽可能地更好的方式.当URL自动添加到不支持的元素中时(无href或src属性),您可以随时将其添加为自定义属性,特别是在使用数据属性时(如data-href或类似)回合这些.
选择JsonBehavior时有什么考虑？
当您必须返回Json时,最好制作POST请求.在GET请求中,您必须了解可能的含义JSON Hijacking,这也是您必须明确指定允许具有JSON结果的获取请求的原因.
在服务器端处理错误的最佳方式是什么？
处理服务器错误(不能和不应该被抑制)的最佳方法是实际通知用户错误.它的细节通常并不重要,因为用户不是开发精明,而是告诉他们出了问题就可以了.特别是如果你能为他们提供某种解决方案.并且Ajax调用它是将错误返回的错误作为可以用错误处理程序Javascript函数处理的错误.我写了一个blog post that details the whole process,并提供了代码,显示如何正确处理验证错误.我个人认为返回错误是成功的错误.所以我不但这是有争议的.我的控制器动作相当简化了我使用的代码：
[HandleModelStateException]
public ActionResult AddUser(User user)
{
if (!this.ModelState.IsValid)
{
throw new ModelStateException(this.ModelState);
}
// process valid data
}
客户端error()回调是否可以由任何错误(即意外的OutOfMemoryException)触发,或者仅通过可预见的错误(即无效输入)触发？
如前所述,错误应该向用户报告,当他们从他们发起的事情中获得意想不到的结果.不要压制应该报告的错误.但不要太详细.内存异常有点太复杂,无法解释tu通常的电脑用户.报告人类友好和短缺的东西.
以error()回调方式触发的方式导出错误的最佳方式是什么？
看看my blog post并检查代码,看看如何创建由error()函数处理的错误
确保错误回调的最佳方法是获取正确的状态代码和响应文本.
相同blog post
验证错误会导致StatusCode错误,还是应该成为响应验证对象的一部分.
验证错误实际上是警告,应该被视为是这样.这就是为什么您可以在一些网站上看到积极的表单验证模式,该模式也会在数据有效时报告,而不是仅通知用户他们已经犯了另一个错误.验证错误通常源于无效的用户界面体验和信息不足.
在客户端处理错误的最佳方法是什么？
这在很大程度上取决于您的应用程序,但我建议您遵循经过验证的模式,因为用户可能会知道演习,不会混淆它们.为什么你认为OpenOffice使用几乎相同的UI作为Microsoft Office？因为用户知道它是如何工作的,所以它更有可能快速,无痛地熟悉该应用程序.但如果可以的话,不要把用户视为愚蠢的人.使用肯定验证.某些错误也应显示为错误.哦.顺便说一句.我在应用程序中使用不显眼的信息,其中诸如成功操作的信息向用户报告,但不会侵入他们的工作.一会儿会自动消失.类似于GMail做的.它只是通知您邮件已发送,此信息不需要任何确认.
jQuery ajax()functin支持成功和错误的功能,所以使用这两者是明智的.再次：成功返回错误是不对的.我们不需要任何错误功能.我的HandleModelState操作过滤器返回错误,特别是可以使用的400错误代码及其结果.
$.ajax({
url: $(this).attr("href"),data: someDataObj,type: "POST",success: function(data){
// process data
},error: function(xhr,status,err){
if (xhr.status = 400) {
// handle my error in xhr.resposeText
}
else {
// handle other errors that are cause by unknown processing
}
}
});
应该以与验证摘要相似的方式显示意外错误服务器端？也许是一个刚刚“出错的”对话框？客户应该能够区分两者吗？
人们不喜欢大红色警报.如果某些东西是大自然的警告,那么它应该比实际的错误更为友善,阻止你的应用程序正常工作.验证尤其应该非常友好.错误应由用户确认,警告也许不应该.取决于它们的性质.但如果他们应该是,那么他们可能是错误.
我希望这可以为你清除一些东西.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。