I have a Liferay 7.3 MVC Resource Command which is something like this:
public boolean serveResource(
ResourceRequest resourceRequest, ResourceResponse resourceResponse) {
try {
// my code goes here
return false;
}catch(Exception e){
return true;
}
}
I call this Command from JavaScript with this:
var req = new XMLHttpRequest();
req.open("POST", '${upload}', true)
req.onload = function (event) {
console.log("success");
}
req.onerror = function (event) {
console.log("error");
}
// do request
req.send(form_data);
The problem now is that always the "onload" function is called also when the MVC ResourceCommands sends back true in the catch clause.
So my question: How can I know in JavaScript when my ResourceCommand was succesfull or not?
Javadoc isn't all that clear about the purpose of the boolean return type. Especially as GenericPortlet.serveResource has a void return type.
However, thinking about what can happen within your // my code goes here block makes it clearer what to expect: The client can't rely on the boolean result to be signaled back: You could (and typically do) access the ResourceResponse's output stream, send all the data you like, and it can long be at the client when you finally return true; from this code. That means that the framework has no chance to intercept or redirect any communication that has been made already.
Also, a simple true/false return value wound not give you any control over what kind of error is signaled to the client. Is it 401? 404? 418? 500? Or would it return 200 with a HTML error message? A JSON encoded error?
If you rely on the result of this operation: Keep control over it. I can't tell you what the boolean return value is for, but it ain't for the benefit of the browser. You decide if you use a HTTP status code for your error signalling, or a specific payload. And once you implement that, you know what to expect on the JS side.
Remember that you'll have to decide for either "ok case" or "error case" before you ever send any data back to the client. If you started delivering the "ok" result to the client and suddenly run into an Exception, you might have delivered half of it to the client, but can't rely on changing horses, e.g. you can't start over, sending an error message as the response might already be (half) on the way to the browser.