How does jsf.ajax.addOnError actually catch errors?
I didn't find any information about it's mechanism. I only found that it is a error listener.
Wherever you've found the statement that jsf.ajax.addOnError is an error-listener, that source is wrong. The addOnError function adds an error listener (ie, a function you define yourself and that gets called whenever the JSF framework encounters an error situation).
This is straight out of the JSF-2.2 spec, 13.3.6.2:
The jsf.ajax.addOnError function accepts a JavaScript function argument that will be
notified when errors occur during any Ajax request/response cycle. [P1-start-event] The implementation must ensure the JavaScript function that is registered must be called in accordance with the errors outlined in Section TABLE 14-5 “Errors”.[P1-end]
Thus, the "errors" table defines under which conditions your function will get called. Here they are:
httpError: request status==null or request.status==undefined or request.status<200 or
request.status >=300
serverError: The Ajax response contains an “error” element.
malformedXML: The Ajax response does not follow the proper format.
emptyResponse: There was no Ajax response from the server.
JSF implementations basically fire a Ajax request and define internal handlers that get called by the browser when a response arrives. Then, they are required to inspect the response and if one the above conditions are met, they look up if you have registered any functions to be called and execute them if need be (they do a lot more, but that's the part in question here).
Related
Please let me know answer if any one knows about it.In which scope my ajax data send from view to handler in coldbox
When you're making an ajax POST, it gets treated as a brand new request. This means you'll need a separate route and handler for that request.
Within your new handler (let's call it /handlers/data.cfc) you'll want to format your response appropriately for your code. ColdBox comes with some nifty tools to help you do this. One way would be to use renderData() within your handler or view.
Rough example:
event.renderData( type="json", data=yourData );
Once set up correctly, the ajax calling code should receive the formatted data from your new handler as expected.
Side note: I recommend including code samples when asking questions on StackOverflow. It will help those that want to provide assistance understand exactly what you are trying to do.
I am running into strange behavior with IBM Cloud Functions.
I have an Action that is web enabled (WebAction) for which I don't require authentication.
I use Postman (and a browser) to test this new REST endpoint.(left side of the image below)
The result is empty, an actual 204 No Content reponse.
But when I monitor the Action, I can see that it has been invoked and returned the expected JSON (right side of the image below). So the code is executed correctly.
When I perform a commandline invoke:
bx wsk action invoke --result talkToEoffice --param name FunctionWorld
I do see the expected result.
Should I provide additional headers ?
Does this have something todo with synchronous (blocking) or non-blocking ?
Looks like you’re returning an object with a property called greeting. For a webaction the response must include a property called body instead. You can nest greeting under body. See https://github.com/apache/incubator-openwhisk/blob/master/docs/webactions.md#handling-http-requests-with-actions for response requirements.
Using django rest framework with backbone.
Current situation:
Whenever an ajax call fails, django responds through get_error_response
As soon as get_error_response gets invoked, django raises a error on client side too, as i am not handling this error in django(server) side.
views.py snippet
def get_error_response(self):
return Response(
self.serializer.errors, status=status.HTTP_400_BAD_REQUEST
)
Requirement:
I want to be able to pass all error statuses to $ajax.fail() promise, and handle it there on client side, thereby enabling me to show the error messages to user.
Note:something like the code given below is what i am expecting. But the problem is, this response would got to $ajax.done promise(), wheras i want it in $ajax.fail() promise
def get_error_response(self):
return Response({
"msg":self.serializer.errors, "error_status":status.HTTP_400_BAD_REQUEST
})
Do ask if more clarity is required.
No matter if you're using a Response from Django Rest Framework or the normal Django HttpResponse you always need to pass the keyworded argument status in order to make the response actually have the correct status code thus invoking the correct handler in your front end code.
What your last example does is only passing a data or content argument which is making the response class default to a 200 status code.
return Response(your_data, status=404)
Using ajax to get HTML content from GSP template .
$.get(url,{word:$('#search').val()},fnback)
The browser Console raises 500 error .
However , we get the expected response , but in browser not in callback .
Known that this kind of error appears only in production environment .
This question is related to this ticket
The error is caused either by Grails or by your application, you will need to determine why; it certainly seems to be happening relatively late in the pipeline since you are getting the correct HTML back (I assume you aren't explicitly rendering a 500 status code in your code by accident).
As for the response you are getting back, it is ignored due to the 500 status. The $.get function accepts a callback which is only invoked on successful requests. If you put debug lines into your fnback function you will see it is never called. If you were to replace the $.get with an equivalent $.ajax call and provide an error callback, that function would get the HTML you are seeing returned in the browser's dev tools.
Based on #Gregor Petrin answer :
$.get(myurl,{word:word},function(d){
$('div#resp').html(d)
})
has been replaced by :
$.ajax({url:myurl,data:{word:word}}).always(function(d,status){
if(status !=='success'){
d=d.responseText;
}
$('div#resp').html(d);
});
I'd like to know what the success and error do in the Ember.js RESTAdapter's ajax function.
hash.success = function(json) {
Ember.run(null, resolve, json);
};
hash.error = function(jqXHR, textStatus, errorThrown) {
Ember.run(null, reject, jqXHR);
};
I know hash is the data sent through AJAX, but what role do success and error play? I assume they'd be run based on a successful or erroneous AJAX response, right? They're set before the AJAX is called, as callbacks? How do they work?
but what role do success and error play? I assume they'd be run based on a successful or erroneous AJAX response, right?
Right, since ember uses jQuery under the hood the functions mentioned are just plain jQuery methods.
They're set before the AJAX is called, as callbacks? How do they work?
As for the functions itself, see this info taken from the jQuery official docs:
error callback option is invoked, if the request fails. It receives the jqXHR, a string indicating the error type, and an exception object if applicable. Some built-in errors will provide a string as the exception object: "abort", "timeout", "No Transport".
success callback option is invoked, if the request succeeds. It receives the returned data, a string containing the success code, and the jqXHR object.
I should also mention that the success callback is in recently jQuery version being replaced with done and is marked as deprecated as noted here:
Deprecation Notice: The jqXHR.success(), jqXHR.error(), and jqXHR.complete() callbacks are deprecated as of jQuery 1.8. To prepare your code for their eventual removal, use jqXHR.done(), jqXHR.fail(), and jqXHR.always() instead.
But don't worry, because I guess until jQuery removes this methods completely the ember team has surely catched up with the new callback versions.
And finally if you where wondering what the call to Ember.run does you can have a look here. But basically it ensures that the passed target and method are run inside of a RunLoop, ensuring also any deferred actions like bindings and views updates, this are flushed at the end. This SO answer on the Runloop is also very informative.
Hope it helps.