Enhance Jester Callback to include the "transport"?

[Neville]

It would be nice if Jester could include the transport as a second
parameter to the async user callback so I could handle any failures
with more detail, eg, something like:

Post.find(1, function(row, transport) {
if (row) {
// got one
}

if (!row) {
//something went wrong ... take a look at the transport.status etc
}

});

This would be really nice as currently my Rails app will return an
ActiveRecord set on success, or an error object [which Jester ignores]
on failure.

Thoughts?

[Neville]

Alternately, it might be better to pass the Prototype transport
options as an additional parameter to the find(), ie

var transportOptions = {
onFailure: function(transport) { //my error handler}
}

var gotOne = function(row) { // success }

Post.find(1, {}, gotOne, transportOptions);

[Neville]

And finally, a third possibility [does Jester already handle this?] to
provide a "jesterCallback" option merged with the Prototype transport
callbacks, ie,

Post.find(1, {}, {
jesterCallback: function(row) {
//jester calls this
},
onFailure: function(transport) {
// my error handler
}
});

[Eric Mill]

If you pass in a callback function directly, like in your example, you
get the Jester object passed into your callback. But, Jester passes
on arguments like onFailure right to Prototype, so you can specify
that in your Jester call instead of a callback function. It'll be
dealt with directly from inside Prototype, so it'll get the transport
passed in as an argument like anything else.

Here are the different ways of calling #find:

Post.find(1, {}, {onFailure: function(transport) { ...},
onSuccess: ...}) // asynchronous
Post.find(1, {}, {onFailure: function(transport) { ...}, asynchronous:
false}) // synchronous
Post.find(1, {visible: true}, jesterCallback) // asynchronous
Post.find(1, jesterCallback) // asynchronous
Post.find(1) // synchronous

If you use the hash form of specifying ajax options, you have to
supply the second hash so that Jester can tell the difference.

Does this do enough to solve your problem? Have you had any issues
trying?

-- Eric

[Neville Burnell]

Hi Eric,

Thanks for your detail.

I would like to be able to make an asynchronous AJAX request, and get the Jester object on success, or the transport on failure.

My attempts resulted in getting the Jester object on success and null on failure, ie, the standard Jester call, or the transport object on bother success and failure via the prototype callbacks.

The hybrid result which would allow me to deal with the jester object on success and failure in detail seems to elude me.

Kind Regards

Neville

[Eric Mill]

Ah, okay I see what you mean. And yeah, I don't think there is a way
of getting that hybrid result. On the one hand, I don't like the idea
because if you want to see if it worked, you have to check if the
object's class, instead of a simple test for equality. On the other
hand, if there's a failure the transport would be useful in sorting
out why. I'm inclined to agree with your perspective, does anybody
else have an opinion?

-- Eric

[Nat Budin]

What about throwing a JS exception that contained the transport object?

Nat

[Eric Mill]

Would this give any benefits over passing either null or the transport
into the callback on failure?

Besides maybe the .find(id, ...) call, most operations in Jester should
expect the possibility of failure. If user-entered data is invalid, so
a save() call fails, that shouldn't be treated as an exception, only as
a failed save.

-- Eric

[Nat Budin]

I see your point - and also, for asynchronous calls, exceptions may be
difficult to trap at all.

Alternatively, what about doing this the way ActiveRecord does it -
i.e. on failure, return a datamodel object with a .errors attribute,
containing the error messages? Possibly also a .transport attribute
for debugging purposes, if that would be useful.

Nat

[Eric Mill]

I think we're starting to mix up things here. On save(), Jester does
look for a bunch of errors returned from the server on a failed save,
and stores them in the object's #.errors attribute. So if you do:

post = Post.find(1)
post.email = "invalid email"
post.save()

You can now access post.errors. In the case of an asynchronous
callback, I think it just passes in "true" or "false", which may not be
ideal, but in either case the errors are there.

But this started about how to deal with a failed .find call, where there
would be no model errors, and how to handle that on failure. I like
returning the transport, since that's the only remaining artifact from a
failed find(), but I'm open to other suggestions.

-- Eric

[Neville Burnell]

Personally, I dont favour throwing an exception.

In my app, there are at the moment, 3 controlled failures returned by the server , which are 404: "not found", 401: "access denied", and 500: "internal failure".

On the client, my homegrown api takes multiple optional callbacks: onSuccess, onNotFound, onAccessDenied, and onFailure, and I choose the appropriate callback in the Prototype onComplete callback.

Is there any technical reason to not enhance Jester to always pass the transport object as the last parameter to the jester callback, ie

Post.find(1, {}, function(resultset, transport) { ...});

This would be backward compatible with the current api and the transport is simple ignored by those who are not interested.

An alternative way forward for me would be to continue to use the Prototype callbacks, and construct the Jester resultset manually - is there an api for that? ie some thing like

resultset = Post.fromJSON(json);

Thanks again for your comments

[Eric Mill]

Prototype's Ajax.request method sends any JSON returned in the
response's X-JSON header as the second argument to callbacks you
provide. Jester, so that this data isn't lost, passes it right through
as the second argument to the callback you provide. So that actually
already has residence as the second optional argument to your callback.

But, there's no reason that can't move from the 2nd to the 3rd slot -
it'd break backwards compatibility, but I'm thinking it'll be okay.

-- Eric

[Neville Burnell]

Hold off for a bit - I'll take another at the code and modify my local copy first