Return response['location']

Rails
1

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)

2

On Nov 24, 6:34 pm, Tony [email protected] wrote:

}
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

3

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.

On Nov 24, 6:42 pm, Frederick C. [email protected]

4

On 25 Nov 2008, at 10:57, Tony wrote:

status can be sent.

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

Fred

5

On Nov 26, 8:52 pm, Tony [email protected] wrote:

    :status => "#{response.code} #{response.message}")

but the javascript completed before I could get to the debugger.

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

Fred

6

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.

On Nov 25, 11:12 am, Frederick C. [email protected]

7

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.

On Nov 26, 8:58 pm, Frederick C. [email protected]

8

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.

On Nov 26, 9:30 pm, Frederick C. [email protected]

9

On Nov 26, 9:18 pm, Tony [email protected] wrote:

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