JSONSelect

150 39 15 years ago

cubicle67• 15 years ago

I think I'm missing something here, because I can achieve the same using normal js

  stuff = {
    "author": {
      "name": {
        "first": "Lloyd",
        "last": "Hilaiel"
      },
      "drinkPref": [
        "whiskey",
        "beer",
        "wine"
      ],
    }, 
    "thing": "JSONSelect site",
    "license": "(cc) BY-SA"
  }

  stuff.author.drinkPref[0]
  > "whiskey"

bitanarch• 15 years ago

But selecting a list of similar items in plain JavaScript would be troublesome.

kalleboo• 15 years ago

Their site has a pretty bad example. Instead imagine it's an array of authors instead. Then their selector would give you a list of all their favourite drinks, which would require a loop in normal JS.

I think I'd prefer something more XPath-like than CSS myself (as someone linked in another comment)

sambeau3• 15 years ago

I'd love to see a javascript+json version of xquery. It would rock as a templating language.

Naming it might be tricky though.

alinajaf• 15 years ago

Couldn't this be done with a simple map function? Not sure the exact javascript but in ruby it would be as simple as:

  favourite_drinks = authors.map { |a| a[:favourite_drink] }

Internally I'd imagine the language will have to loop through the json anyway. Are there any other benefits I'm missing (apart from of course the nice css-like syntax, which is perfectly valid).

aquark• 15 years ago

But what happens in the case where there is no author element?

With normal javascript you would get an exception .. hopefully with this you just get back undefined without having to check every step in the path.

lloydhilaiel2• 15 years ago

with the reference implementation:

JSONSelect.match(".nonexistantkey .somechild", obj) returns []

Alternately, if you use the JSONSelect.forEach() method your callback will just not be invoked.

So no existence testing before access for recursive values. A main benefit of this thing in javascript.

arethuza3• 15 years ago

That made me wonder if there is something that uses an XPath like approach rather than CSS selectors, turns out there is just such a thing:

http://goessner.net/articles/JsonPath/

These tools could be fun for writing map functions for CouchDB.

audionerd2• 15 years ago

You might want to check out RQL, which builds on JsonPath:

  http://www.sitepen.com/blog/2010/11/02/resource-query-language-a-query-language-for-the-web-nosql/

anarchitect• 15 years ago

I've been using jLinq - http://www.hugoware.net/Projects/jLinq

mhansen• 15 years ago

Please someone make this into a commandline utility that lets you pipe and query JSON around. My toolkit is missing a JSON slicer and splicer.

lloydhilaiel2• 15 years ago

I hope to build jsonselect support on top of yajl and expose it as a native command line tool, so fast stream based filtering... but that's still ideaware at this moment :)

arethuza3• 15 years ago

I thought "that would be interesting to build, I could call it jsawk" - turns out it exists already:

https://github.com/micha/jsawk

haberman• 15 years ago

https://github.com/benbernard/RecordStream

perlpimp• 15 years ago

Frankly it feels alot like LDAP.

GlennS• 15 years ago

My gut reaction is that 'feels like CSS' is not a selling point.

zdw• 15 years ago

My prediction is that JSON will eventually reach feature parity with XML (this is quite similar to XPath), then we'll dump it for YAML or something.

Great.

wvenable• 15 years ago

JSON is almost the simplest untyped text-based tree serialization format that could possibly be designed. In terms of complexity, XML and YAML are closer together.

arethuza3• 15 years ago

I'd argue that Lisp s-expressions are simpler.

Macha• 15 years ago

A large amount of JSON is actually valid YAML.

Ixiaus3• 15 years ago

I doubt it ever will. The reason why I use JSON is because it's a very simple data format; when I need more expressive and structured data interchange I always fallback on XML+XSD+XSLT - something JSON will probably never catch up with (because that already exists and why make JSON needlessly complex in order to handle what that kind of stack does?).

I think web developers get caught up in bashing XML a lot for no good reason - just because it isn't directly applicable to a simple RESTful API doesn't mean it isn't incredibly useful, it's meant for machines anyway!

true_religion• 15 years ago

XMLs great promise was that it was human readable. Lo and behold, it is more readable by non-bit-addled humans than whatever binary format is used in COBRA RPC.

But no, XML wasn't meant for machines... its just that people today programatically generate and consume XML far more often than they do it by hand.

nerd_in_rage• 15 years ago

CSS is the worst. And this seems unnecessarily verbose: nth-child(1)

Groxx3• 15 years ago

I'd imagine it wouldn't be hard to tweak the library to use "nc(1)" instead.

For "real" CSS in particular, I prefer a bit of verbosity over awk-like code. And you should likely be using a CSS generator anyway, it doesn't even have variables, for Knuth's sake :/

audionerd2• 15 years ago

It would be great to see a standard emerge here. I've watched with interest as JSONPath and JSONQuery proposals have been presented, JS ports of Linq, and this latest proposal: RQL –

http://www.sitepen.com/blog/2010/11/02/resource-query-langua...

There's an Arel-style JS implementation to build RQL strings using chained methods, which makes it quite conducive to composition and makes it feel more like functional programming.

Along those lines are D3's selections:

  http://mbostock.github.com/d3/#selections

... and jLinq

  http://www.hugoware.net/Projects/jLinq

blago• 15 years ago

As far as selectors go, it looks a lot better than JSONPath. I wonder how do they compare in speed.

JSONSelect

Related Stories