Forum: Ruby on Rails return response['location']

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tony (Guest)
on 2008-11-24 20:37
(Received via mailing list)
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)
Frederick C. (Guest)
on 2008-11-24 20:43
(Received via mailing list)
On Nov 24, 6:34 pm, Tony <removed_email_address@domain.invalid> 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
Tony (Guest)
on 2008-11-25 12:59
(Received via mailing list)
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. <removed_email_address@domain.invalid>
Frederick C. (Guest)
on 2008-11-25 13:13
(Received via mailing list)
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
Tony (Guest)
on 2008-11-26 22:53
(Received via mailing list)
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. <removed_email_address@domain.invalid>
Frederick C. (Guest)
on 2008-11-26 22:59
(Received via mailing list)
On Nov 26, 8:52 pm, Tony <removed_email_address@domain.invalid> 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
Tony (Guest)
on 2008-11-26 23:19
(Received via mailing list)
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 :)

T.

On Nov 26, 8:58 pm, Frederick C. <removed_email_address@domain.invalid>
Frederick C. (Guest)
on 2008-11-26 23:31
(Received via mailing list)
On Nov 26, 9:18 pm, Tony <removed_email_address@domain.invalid> 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
Tony (Guest)
on 2008-11-26 23:43
(Received via mailing list)
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. <removed_email_address@domain.invalid>
This topic is locked and can not be replied to.