return response['location']

I'm building an extension to an existing Rails app but have hit a problem the developers cannot seem to help me with. From a javascript- based shadowbox, I post an addition to a RDF triplestore via a proxy call: with the following in the Rails app ('uri' is the triplestore address, 'claim' the RDF to be added):

response = Net::HTTP.start(uri.host, uri.port) { |http|   http.request_post(uri.path, claim, { 'Content-type' => 'text/ turtle' }) }

and want to return the triplestore response to the javascript call. I was told to use:

send_data(response.body, :type => response['content-type'],     :status => "#{response.code}")

which half works. But I need to return the response['location'] value as it contains the uri of the added rdf. But send_data does not seem to allow the return of the location: is there any way that I can do this?

Thanks, Tony.

(Apologies if this is a simple or stupid question: I'm trying to do this complex (to me) stuff with very little Rails knowledge)

I'm building an extension to an existing Rails app but have hit a problem the developers cannot seem to help me with. From a javascript- based shadowbox, I post an addition to a RDF triplestore via a proxy call: with the following in the Rails app ('uri' is the triplestore address, 'claim' the RDF to be added):

response = Net::HTTP.start(uri.host, uri.port) { |http| http.request_post(uri.path, claim, { 'Content-type' => 'text/ turtle' })

}

and want to return the triplestore response to the javascript call. I was told to use:

send_data(response.body, :type => response['content-type'], :status => "#{response.code}")

which half works. But I need to return the response['location'] value as it contains the uri of the added rdf. But send_data does not seem to allow the return of the location: is there any way that I can do this?

Where were you planning on storing it ? It's either the body or a header of some sort. For a javascript client you might set response.headers['X-JSON'] = {:location => foo}.to_json Prototype response handlers get passed this header (after it has been parsed into a JS object)

Fred

Thanks for the reply, Fred. It isn't for storage, just to assure the user that it has been received by the triplestore.

I'm afraid I'm too much of a novice to understand what you've suggested. The response variable contains the return I received from the triplestore which includes the location as response['location'] and I just want to send this response back to the javascript client. If I set the response.headers['X-JSON'] as you've suggested, how does this get to the client using send_data as it seems only body, type and status can be sent.

Cheers, Tony.

Thanks for the reply, Fred. It isn't for storage, just to assure the user that it has been received by the triplestore.

I'm afraid I'm too much of a novice to understand what you've suggested. The response variable contains the return I received from the triplestore which includes the location as response['location'] and I just want to send this response back to the javascript client. If I set the response.headers['X-JSON'] as you've suggested, how does this get to the client using send_data as it seems only body, type and status can be sent.

It just does. send_data won't unset headers previously set.

Fred

Thanks, Fred. Though it looks a bit more complicated. I was going to test your suggestion and so stuck a breakpoint in proxy_controller before the send_data:

    response = Net::HTTP.start(uri.host, uri.port) { |http|       http.request_post(uri.path, claim, { 'Content-type' => 'text/ turtle' })     } debugger     send_data(response.body, :type => response['content-type'],         :status => "#{response.code} #{response.message}")

but the javascript completed before I could get to the debugger. The js (using prototype) looks like:

  new Ajax.Request('/proxy',    {      method:'post',        parameters: { 'claimType': claim_type, 'claimId': claim_id, 'sacURL':sac, 'notes':notes, 'rating':rating, 'tags':tags.toString () },      onSuccess: function(transport){         alert('Added claim at: ' + transport.body);        Shadowbox.close();        return;      },      onFailure: function(transport){        alert('Something went wrong...\nProbably incorrect SAC address\n \nStatus: ' + transport.status + 'Text: ' + transport.responseText);      Shadowbox.close();        return;      }    });

so it looks as though the post is coming back as successful before the proxy_controller can do the send_data though the page is held up from refreshing until proxy_controller completes.

Why would this be? I thought the post to /proxy would not know whether the post was complete and successful or not (same thing happens if I change onSuccess to onComplete) until the proxy_controller has finished.

Hmm, maybe the post is asynch. I'll do some more digging but any suggestions meantime would be appreciated.

Cheers, Tony.

As in the onComplete was called ? did you start the server with the -- debugger option ?

Fred

Yes, I did and it waits for me to type continue.

Just checked Prototype docs and it seems Ajax.Request is asynch so I guess the complete/success states merely relate to making the call rather than getting anything back from the callee.

Yes, setting 'asynchronous: false' in the request does hold up the onSuccess. And it enables any error to be trapped by the onFailure.

So, although it is considered bad practice, seems I have no option but to use a synchronous call to the proxy_controller otherwise the success/failure does not work.

now back to the send_data issue :slight_smile:

T.

Yes, I did and it waits for me to type continue.

Just checked Prototype docs and it seems Ajax.Request is asynch so I guess the complete/success states merely relate to making the call rather than getting anything back from the callee.

That's incorrect. onSuccess/onComplete are called when a response is received from the remote server (half the point of those callbacks is to do something with the response from the server)

Fred

That's what I would have thought. Maybe it is Rails and how it handles asynch requests- wil dig some more tomorrow - got an early flight so off to bed.

Cheers, Tony.