I'm new to clojurescript and would like to do a deeper dive by implementing a previously written application purely in clojurescript, but am at a loss with respect to to implement an ajax call. Can anyone point me to an example online or provide me with a code snippet or two?
January 22, 2016 update
Although it still works, the original answer is from a time when there was a general lack of ClojureScript solutions with more than 1 contributor. Rather than leveraging XhrIo directly, definitely consider using a well-maintained, feature-rich solution that wrappers it instead like cljs-ajax, as suggested by Mikhail D below!
Okay, So given that Clojurescript leverages Google's Closure JavaScript library, a quick search of the Closure Documentation yielded xhrIo as the proper method for generating AJAX calls:
Example using Closure's Asynchronous XMLHttpRequests with XhrIo
goog.net.XhrIo.send(url, opt_callback, opt_method, opt_content,
opt_headers, opt_timeoutInterval)
A quick review of the Clojurescript source revealed the following function:
From src/cljs/clojure/browser/net.cljs in clojure / clojurescript
(defn xhr-connection
"Returns an XhrIo connection"
[]
(goog.net.XhrIo.))
So something along the lines of this should have the intended results:
(def xhr xhr-connection)
(defn myCallback [replyValue]
... Do Something with replyValue
... for example: (someJsonFunc (.getResponseJson (.target replyValue))))
(defn ajax-json [url]
(.send xhr url myCallback))
For JSONP, you can do something similar using the goog.net.Jsonp. See the link for details:
JSONP Closure API
Hope someone finds this helpful!
An another viable option could be https://github.com/JulianBirch/cljs-ajax
Since it's designed for ClojureScript, the syntax looks clearer and simpler. It also supports a lot of features out of the box (for example: transit, edn and json formats).
Some examples from a README:
(ns foo
(:require [ajax.core :refer [GET POST]]))
...
(GET "/hello" {:handler handler
:error-handler error-handler})
(POST "/send-message"
{:params {:message "Hello World"
:user "Bob"}
:handler handler
:error-handler error-handler})
The way I did it is slightly different. I don't know why the way that Marc suggested in his answer didn't work for me. Hopefully this is also useful.
I used goog.net.XhrIo directly, rather than the xhr-connection wrapper.
(defn callback [reply]
(let [v (js->clj (.getResponseJson (.-target reply)))] ;v is a Clojure data structure
(your-function-here v)))
(.send goog.net.XhrIo url callback)
The main difference that I can see is that I've used .-target to get the property of the JSON object, rather than calling target.
It's worth noting that maps in v that have been created from JSON objects are keyed by strings not keywords.
Related
I'm using Yesod to build an Ajax app (using jQuery, though I don't think that matters too much for my question). Basically, what I'd like is for the server to send different representations of the same data depending on whether or not the XMLHttpRequest header got sent. (The point of all of this is to use a javascript library like history.js
In particular, I'd like to have a route like:
/picture/#PictureId GET
Which, when accessed without the XHR header, gets handled by going to the default layout -- or better yet, by a widget which will ultimately get wrapped by the default layout, and when accessed by an XHR request, just sends an HTML representation of the widget.
How should I approach this? I guess I can make a custom defaultLayout-like function to wrap Widgets in logic. Is that sensible, or is there a better approach?
Edit: I decided to override the defaultLayout method in the Yesod class to:
defaultLayout widget = do
req <- waiRequest
let reqwith = lookup "X-Requested-With" $ requestHeaders req
when (maybe False (== "XMLHttpRequest") reqwith) $ do
(PageContent _ _ w) <- widgetToPageContent widget
giveUrlRenderer $ [hamlet| ^{w} |]
...
But now I'm getting a type error I don't quite understand
Couldn't match type `blaze-markup-0.5.1.5:Text.Blaze.Internal.MarkupM ()'
with `()'
Expected type: HandlerT App IO ()
Actual type: HandlerT
App IO (blaze-markup-0.5.1.5:Text.Blaze.Internal.MarkupM ())
You should take a look at this chapter: http://www.yesodweb.com/book/restful-content.
Suppose I want to be able to write a test like this:
lambda {
do_something_involving_web_requests
}.should make(1).http_requests
It seems to me there would be several possible ways to implement this kind of functionality; however, it also seems that:
Someone might have already done so (in which case I want to look into their solution); or
Someone on StackOverflow might have an idea I haven't thought of.
So, has this been done already? And/or what are your ideas?
If you're interested in more granular testing of how your app responds to specific HTTP responses, rather than simply counting requests, you can use mocks. Here's how to use RSpec's mocks to test http requests:
#mock_http = mock("http")
Net::HTTP.stub!(:start).and_yield #mock_http
#mock_http.should_receive(:get).with("/")
One library I use is Fakeweb. Fakeweb does what #Joe mentions: it hooks into Net::HTTP and can be configured to return a canned response from a given URL. Many other HTTP libs depend on Net::HTTP so this technique has broad compatibility. Fakeweb example from its docs:
FakeWeb.register_uri(:get, "http://example.com/test1", :body => "Hello World!")
Net::HTTP.get(URI.parse("http://example.com/test1"))
=> "Hello World!"
Neither of these methods have a simple access count though, if you want that you can use rspec-mocks which has the following method count functionality (these can be used on stubs or test doubles):
double.should_receive(:msg).once
double.should_receive(:msg).twice
double.should_receive(:msg).exactly(n).times
double.should_receive(:msg).at_least(:once)
double.should_receive(:msg).at_least(:twice)
double.should_receive(:msg).at_least(n).times
double.should_receive(:msg).at_most(:once)
double.should_receive(:msg).at_most(:twice)
double.should_receive(:msg).at_most(n).times
double.should_receive(:msg).any_number_of_times
I'm trying to use iChemLabs cloud services from a html5 web worker. Normally the cloudservices requires jQuery but I can't import that into a web worker so I'm using Pollen instead with a ChemDoodle Web Components library with which I have stripped out the document-related things.
jQuery.Hive.Pollen provides a nice ajax function very similar to jQuery, but I can't seem to get it to work at all. I know this problem will be tricky to solve considering that Access-control-headers need to be set to allow any of you to actually find the solution. However, I'm a beginning javascript programmer and I was wondering if my two weeks of frustration is actually a small difference. I am trying to invoke the following function:
var cloudmolecule;
ChemDoodle.iChemLabs.readSMILES('N1(C)C(=O)N(C)C(C(=C1N1)N(C=1)C)=O', function(mol){
cloudmolecule = mol;
});
Here is a link to the library code I am using, see the 'q.ajax' call and substitute jQuery = q for p = q (p is for pollen) in that block of code.
Right now I'm just trying to get the ajax call to work in an ordinary block of javascript with the plan to migrate to a web worker later.
If anybody could point out the problem to me I would be extremely grateful.
solved! turns out iChemLabs rejects these two extra headers that pollen creates:
_xhr.setRequestHeader("X-Requested-With", "Worker-XMLHttpRequest");
_xhr.setRequestHeader("X-Worker-Hive", "Pollen-JS" );
Simply comment them out
Also, Pollen ajax seems to return a JSON object containing the data in JSON format AND as a string, so do
o = JSON.parse(data.string)//data is the parameter to the callback function
The reduced ChemDoodle library (without document-related methods) will work like a charm with pollen ajax.
I'm just starting to dabble in consuming a JSON web service, and I am having a little trouble working out the best way to get to the actual data elements.
I am receiving a response which has been converted into a Ruby hash using the JSON.parse method. The hash looks like this:
{"response"=>{"code"=>2002, "payload"=>{"topic"=>[{"name"=>"Topic Name", "url"=>"http://www.something.com/topic", "hero_image"=>{"image_id"=>"05rfbwV0Nggp8", "hero_image_id"=>"0d600BZ7MZgLJ", "hero_image_url"=>"http://img.something.com/imageserve/0d600BZ7MZgLJ/60x60.jpg"}, "type"=>"PERSON", "search_score"=>10.0, "topic_id"=>"0eG10W4e3Aapo"}]}, "message"=>"Success"}}
What I would like to know, is what is the easiest way to get to the "topic" data so I can do something like:
topic.name = json_resp.name
topic.img = jsob_resp.hero_image_url
etc
You can use Hashie's Mash . One of the best twitter clients for ruby uses it, and the resulting interface is very clean and easy to use. I've wrapped over Delicious rss api with it in less than 60 lines.
As usuall, the specs show very clearly how to use it.
I'm dealing with a SOAP webservice call from a server that is expecting to receive method calls with the paramaters in the format of:
<urn:offeringId> 354 </urn:offeringId>
But SOAP::RPC::Driver is generating messages in the form of:
<offeringId xsi:type = "xsd:int">354</offeringId>
The server keeps erroring when it gets these messages (especially since it's expecting offeringId to be a custom type internal to itself, not an int).
Is there anyway to configure the driver to format things the way the server is expecting it. Is the server even doing SOAP? I'm having trouble finding reference to that style of formating for SOAP (I know it DOES work though, because SOAPUI works just fine with that type of message).
-Jenny
Edit: I've got at least part of it solved. the RPC::Driver (obviously) uses the RPC standard, whereas apparently the server I'm trying to talk to is doing "document". Now, when I look at RPC::Driver's API, I'm seeing a method named "add_document_method". That SOUNDS to me like it might be what I want, but I can't figure out what paramaters to give it. The examples I've seen around the net don't make much sense to me, things like:
def GetNamePair(response)
response.account.each do |x|
class << x
attr :configuration, true
end
x.configuration = Hash[*x.a.map do |y|
[y.__xmlattr[XSD::QName.new(nil, 'n')], String.new(y)]
end.flatten]
end
end
mNS = 'urn:zimbraAdmin'
drv.add_document_method('GetAllAdminAccountsRequest', mNS, [XSD::QName.new(mNS, 'GetAllAdminAccountsRequest')],
[XSD::QName.new(mNS, 'GetAllAdminAccountsResponse')] )
puts YAML.dump(GetNamePair(drv.GetAllAdminAccountsRequest([]))
All I really know is that I have a method that takes in certain parameters.... I really don't get why, if this method does what I think it does, it has to be more complicated. Isn't this just a matter of taking the exact same data and formating it differently? I'm so confused....
Okay, what I ended up doing was using SOAP:RPC:Drivers add_document_method, which requires me to give it the wsdl, namespace, etc, and then give it the attributes later as a single input hash thingy (and gives me the output in a similar format). It worked, it just wasn't as clean as add_rpc_method (which is waht add_method defaults to)
-Jenny