Let NSJSON parse top-level objects. #374

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
@drewish

drewish commented Jun 13, 2012

I've got an API returning 'true' and 'null' JSON responses. It seems better
to be liberal in what we accept.

If this approach is problematic could we have a way of setting the options?

Let NSJSON parse top-level objects.
I've got an API returning 'true' and 'null' JSON responses. It seems better
to be liberal in what we accept.
@drewish

This comment has been minimized.

Show comment Hide comment
@drewish

drewish Jun 13, 2012

If you're interested in how this came up see this issue: workhabitinc/drupal-ios-sdk#43

drewish commented Jun 13, 2012

If you're interested in how this came up see this issue: workhabitinc/drupal-ios-sdk#43

@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Jun 13, 2012

Contributor

Thanks for your pull request, @drewish.

I'm hesitant to pull this in for a few reasons. First, true and null (or String or Numeric literals, for that matter), are not valid JSON by themselves. Second, since AFJSONDecode coordinates across a few different JSON libraries, I want them to have reasonably similar behaviors; I don't think all, or even any of them, have a similar option.

Contributor

mattt commented Jun 13, 2012

Thanks for your pull request, @drewish.

I'm hesitant to pull this in for a few reasons. First, true and null (or String or Numeric literals, for that matter), are not valid JSON by themselves. Second, since AFJSONDecode coordinates across a few different JSON libraries, I want them to have reasonably similar behaviors; I don't think all, or even any of them, have a similar option.

@drewish

This comment has been minimized.

Show comment Hide comment
@drewish

drewish Jun 13, 2012

I can definitely understand that. Any thoughts on providing a way to set that option then?

drewish commented Jun 13, 2012

I can definitely understand that. Any thoughts on providing a way to set that option then?

@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Jun 13, 2012

Contributor

Sorry to say that's not really a priority. You always have to option to override at a lower level by writing your own completionBlock that parses JSON your way from responseData. FWIW, for true/false/null, those should probably be handled by HTTP status codes (404, etc.)

Contributor

mattt commented Jun 13, 2012

Sorry to say that's not really a priority. You always have to option to override at a lower level by writing your own completionBlock that parses JSON your way from responseData. FWIW, for true/false/null, those should probably be handled by HTTP status codes (404, etc.)

@mattt mattt closed this Jun 13, 2012

@drewish

This comment has been minimized.

Show comment Hide comment
@drewish

drewish Jun 14, 2012

Yeah it's definitely a wacky API. I'll report a bug upstream there too. The completionBlock sounds like a good tip, thanks!

drewish commented Jun 14, 2012

Yeah it's definitely a wacky API. I'll report a bug upstream there too. The completionBlock sounds like a good tip, thanks!

@drewish

This comment has been minimized.

Show comment Hide comment
@drewish

drewish Jun 14, 2012

Also thanks for the quick response. Much nicer to have a quick no than just having it ignored.

drewish commented Jun 14, 2012

Also thanks for the quick response. Much nicer to have a quick no than just having it ignored.

@mattt

This comment has been minimized.

Show comment Hide comment
@mattt

mattt Jun 14, 2012

Contributor

Sure thing. Thanks for pointing this out.

Contributor

mattt commented Jun 14, 2012

Sure thing. Thanks for pointing this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment