Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JsonConvert.DefaultSettings #78

Closed
JamesNK opened this issue Apr 27, 2013 · 9 comments

Comments

@JamesNK
Copy link
Owner

commented Apr 27, 2013

Problem

The project I'm working on right now is using Json.NET in four places: Web API server, Web API client, ViewResult from MVC and HtmlHelper extension for MVC views.

The problem is I'm using custom serialization settings and I have to make sure each place uses the same settings. While configuring all these places to use the same JsonSerializerSettings was simple enough, it made me wish I could do it once and then not have to think about it anymore.

Also configuring each place individually requires you to know how it is done in each different library. For example the way to customize Json.NET in Web API and SignalR are completely different.

SignalR - https://github.com/SignalR/SignalR/wiki/Extensibility#replacing-the-ijsonserializer
WebAPI - http://stackoverflow.com/questions/13274625/how-to-set-custom-jsonserializersettings-for-json-net-in-mvc-4-web-api

Solution

To solve this issue I want to add the ability to set global default settings. Set once with JsonConvert.DefaultSettings, the default settings would automatically be used by all calls to JsonConvert.SerializeObject/DeserializeObject, and JToken.ToObject/FromObject. Any user supplied settings to these calls would override the default settings. If someone decided they want to configure some default settings then it would still be possible to customize SignalR using its current configuration functional if required.

JsonSerializers created from the constructor or with JsonSerializer.Create(settings) would not use DefaultSettings to provide the option for library authors to opt-out if they don't want users to ever change how they serialize JSON. Library authors who do want users to be able to set default settings (i.e. Web API, SignalR, RavenDB) would call new factory methods JsonSerializer.CreateDefault() or JsonSerializer.CreateDefault(settings) when creating a JsonSerializer.

Example

JsonConvert.DefaultSettings = () => new JsonSerializerSettings
  {
    Formatting = Formatting.Indented,
    Converters = { new StringEnumConverter() }
  };

// uses default settings
string json = JsonConvert.SerializeObject(new [] { 1, 2, 3 });

// uses default settings
JsonSerializer s1 = JsonSerializer.CreateDefault();

// does not use default settings
JsonSerializer s2 = new JsonSerializer();

All calls to SerializeObject/DeserializeObject, FromObject/ToObject and any libraries that create their serializer with JsonSerializer.CreateDefault() will automatically indent JSON and serialize enums to their string name. The developer no longer needs to worry about JSON configuration.

Good idea?

I'm pretty certain that developers being able to set default settings once and have all their code and libraries using Json.NET pick them up is something people will find useful.

What I'm wondering is are there security problems with being able to set default settings globally? All the popular libraries that use Json.NET already provide hooks to customize their JSON serialization so that doesn't seem like a big deal. Additionally to be sure I've made it so you have to opt-in when creating a JsonSerializer.

Thoughts? Are there any issues I haven't though of? Do my names suck?

Comment below!

🤘

@JamesNK

This comment has been minimized.

Copy link
Owner Author

commented Apr 28, 2013

Implementation + tests a7d4755

@avanderhoorn

This comment has been minimized.

Copy link

commented Apr 29, 2013

For tools like Glimpse this feature would be fantastic. It would mean that we could start pulling out diagnostics information from Json.NET and start feeding that back to users - total time spent seralizing objects, etc.

@drub0y

This comment has been minimized.

Copy link

commented May 1, 2013

Love it and don't really see any negative impact because you're maintaining the ability to configure explicitly in all the ways you would have to today anyway.

@daniel-white

This comment has been minimized.

Copy link

commented May 1, 2013

👍

@Athari

This comment has been minimized.

Copy link
Contributor

commented May 5, 2013

Is it really necessary to make JsonConvert.DefaultSettings a delegate?

@JamesNK

This comment has been minimized.

Copy link
Owner Author

commented May 5, 2013

It means new settings will be created each time the serializer is used which is useful for stateful types like IReferenceResolver.

@Athari

This comment has been minimized.

Copy link
Contributor

commented May 5, 2013

Why not just clone?

@JamesNK

This comment has been minimized.

Copy link
Owner Author

commented May 5, 2013

  1. Some types like IContractResolver might be a singleton with cached information and shouldn't be cloned.
  2. You can't safely clone unknown types.

@JamesNK JamesNK closed this May 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.