On 07/25/2011 10:09 PM, Jared Casper [via Databinder] wrote:
> My question is how to use the dispatch.twitter.Search object
> effectively. I get how the SearchBuilder works in creating a
> request/handler object ready to be executed. Executing it gives me a
> (HttpPackage wrapping a) List of JsObjects. What I don't see, and
> this is probably my lack Scala experience/knowledge, is how to use the
> extractors contained in the Search object to easily get at the data in
> the List of JsObjects. I can get at the fields individually (i.e.
> "res map { _ match { case Search.from_user(u) => u } }" to get a List
> of the users). But is there way to extract all of the fields together
> into an object?
Lift-json can deserialize into case classes, as can a few other
libraries. I'm not a big fan of this method when used with APIs outside
your control, as it assumes that the API will forever conform to what
you've defined in the case class, and what case classes in general can
represent. For example, there is an upper bound on the number of fields
a case class can have in Scala (the number of parameters its constructor
can have), and JSON does not share this constraint. Nulls are also
problematic; will your class use Options everywhere, or assume that
nulls or missing fields do not occur?
So instead I tried to come up with ways to succinctly define the
expected object-path to and type of a value, and if it's not there in
that format then it's None or Nil. The dispatch-http-json module was the
first pass at that.
> Or how are those extractors typically used? Is there an example use
> of the Twitter client beyond the very simple spec test (i.e. uses the
> Search, Account, User, etc. objects)
The only other example I've done is the twine app, but it just uses
lift-json ad-hoc to get at the fields it needs.
> Or maybe a more general question: is there any docs/examples of using
> the native dispatch json package? Is there any reason to use it over
> the lift json package? In any case, I'd like to understand fully how
> it works to further my scala knowledge.
There really isn't a reason to use dispatch-json, now. If you want to
use that kind of parser you should use Spray [1], which is apparently
based on it. I switched over to lift-json myself when I found that
parser-combinators (such as dispatch-json uses) didn't work on Android.
At that point I took a second pass at defining terms to create schemata
for json API results, which you can find in the dispatch-lift-json
module. The Meetup API integration has a extensive definitions in this
form [2] and you can even find them productively used in the Snapup
Android app [3].
I think these experiments showed some promise but ultimately the
interaction is just to *weird*, as it stands. Even I have a hard time
remembering how they work. I want a more natural way of exactly what
they do--enabling the static definition of what is expected from a json
structure, which fails softly when the data does not conform. Since json
traversal is such a big deal I assume that someone will solve this
properly at some point, and then I can just offer a binding for this in
Dispatch.
[1]:
https://github.com/spray/spray-json[2]:
https://github.com/n8han/dispatch-meetup/blob/master/src/main/scala/Meetup.scala#L92[3]:
https://github.com/meetup/snapup-android/blob/master/src/main/scala/Meetups.scala#L40Nathan
Locked
