Parse json with capitalized keys

[Albert Sikkema]

Hi,

Maybe a stupid question, but I'm trying to use spray-json to parse json from external API. Unfortunately the json returned is capitalized (the keys start with a uppercase letter). 

example: 

{

   "Key": "somevalue"

}

of course I can simply use the jsonFormat methods instead of the convenience methods provided. But it would be nice if I could indicate somewhere to match on fields case insensitive. The matching is done in ProductFormats fromField method, but it's private unfortunately.

It might be useful to others as well as it would allow more freedom in naming your variables in case classes if matching would be case insensitive I think, or not?

Regards,

Albert

[Johannes Rudolph]

Hi Albert,

On Wed, Nov 27, 2013 at 4:43 PM, Albert Sikkema <a.sik...@gmail.com> wrote:
> of course I can simply use the jsonFormat methods instead of the convenience
> methods provided. But it would be nice if I could indicate somewhere to
> match on fields case insensitive. The matching is done in ProductFormats
> fromField method, but it's private unfortunately.

Starting with spray-json 1.2.5 it should be `protected` allowing you
to override its definition. We know of others who do custom name
transformations this way.

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[Age Mooij]

One of those others would be me :)

We have a “snakify” util that translates between CamelCase in Scala and “snake case” in JSON. If you import that one instead of DefaultJsonProtocol than you can use the normal jsonFormatX convenience methods.

Here’s the code:

https://gist.github.com/agemooij/7679130

It’s not the most efficient approach but you can’t beat it for pure convenience :)

Hope this helps
Age

> --
> You received this message because you are subscribed to the Google Groups "spray-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to spray-user+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Mathias Doenitz]

Albert,

just in case the spray-json README is not clear enough on this:
If you have a

case class Foo(a: Int, b: Int, c: Int)

you don't have to use `jsonFormat3(Foo)` to define the `RootJsonFormat[Foo]`.
You can also say

implicit val fooFormat = jsonFormat(Foo, "a", "b", "c")

instead, the result is identical. The `jsonFormatX` methods are simply more convenient.
However, if you need to define custom names for the JSON object members because they somehow don't fit the case class member names than you can simply spell them out manually with the `jsonFormat` method.

Cheers,
Mathias

---
mat...@spray.io
http://spray.io

[Age Mooij]

You’re right, this is usually a better solution and certainly a better performing one.

I think it would be great for lazy developers everywhere if you could map over the auto-detected field names so you can apply some general transform over them. But it should be clear that this has a performance impact.

Age

[Mathias Doenitz]

> I think it would be great for lazy developers everywhere if you could map over the auto-detected field names so you can apply some general transform over them.

Interesting idea, Age, thanks!
We'll keep that in mind when we touch the JSON stuff the next time...

Cheers,
Mathias

---
mat...@spray.io
http://spray.io

[Johannes Rudolph]

On Thu, Nov 28, 2013 at 8:55 AM, Age Mooij <age....@gmail.com> wrote:
> You’re right, this is usually a better solution and certainly a better performing one.

I don't think so. The `jsonFormatX` variants just call the general
variant, so there can only be a difference during building the
formatters not while using them.

> I think it would be great for lazy developers everywhere if you could map over the auto-detected field names so you can apply some general transform over them.

Agreed.

[Albert Sikkema]

Hi Mathias,

This is exactly what I did. Not too bad and flexible enough for me. Took me a while to get there though. Might be because I'm relative new to spray, but it might not be a bad idea to document this more explicitly in the README. If the matching method will become protected in the next release I can always decide to override it. 

@Age: Nice workaround! 

Thanks,

Albert

[Age Mooij]

On Thu, Nov 28, 2013 at 8:55 AM, Age Mooij <age....@gmail.com> wrote:
>> You’re right, this is usually a better solution and certainly a better performing one.
>
> I don't think so. The `jsonFormatX` variants just call the general
> variant, so there can only be a difference during building the
> formatters not while using them.

True, somehow I got it into my head that the transforms would be applied for every (de)serialization but of course they are only used once to generate the list of field names that you can also specify manually.

Age