-
Notifications
You must be signed in to change notification settings - Fork 65
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
switch to newtonsoft.json #3
Comments
Hi, I know Newtonsoft.JSON but IIRC I didn't chose it because of the lacking Could you please open up a pull request so I can review that changes and merge it in? |
Part of the struggles with the library involved missing DLLs. So what I had This is what I see when I load up the solution in VS2010 with no I'll see about doing a pull request and putting my changes in there, but I "By acknowledging the ruse, it is a brilliant ruse" On Mon, Oct 21, 2013 at 1:30 AM, Dynalon [email protected] wrote:
|
Yeah, I'm having struggles with the library, so no-go on the pull request,
var json_reader = new JsonReader (); with:
JsonConvert.DeserializeObject(filtered_json);
That's all I did. Let me know if you have more questions. ~Zack |
I've got a similar patch ready, but I got a few more of the unit tests to pass (up to 25 of 31) and I have it swapping between JsonFx and JSON.Net at compile time. JSON.Net can return the top-level object as an ExpandoObject, but any nested objects don't appear to be ExpandoObjects and there doesn't seem to be a way to give JSON.Net a clue that that's what you want it to do. Even this doesn't help: dynamic parsed = JsonConvert.DeserializeObject(filtered_json, new ExpandoObjectConverter()); The long-term solution for that is probably a change to JSON.Net to tell it that you want it to return the entire object tree as ExpandoObjects instead of just the top level. So, setting that issue aside for the moment, which type of approach do you prefer for switching between JSON libs?
Advantages: simple, hides the incomplete JSON.Net support except for consumers who are willing to compile it on their own or until it's ready for prime time Disadvantages: doesn't work too well for the long-term, it's hard to put two libs into NuGet without people getting confused about what the difference is between them
Advantages: removes the direct dependency between JsonConfig and the JSON lib (which avoids a whole slew of problems with versions of the lib, strong names, etc) Disadvantages: requires this little shim class (how gross is that?) What do you think? Harold |
I think a compile-time options is currently the best option. JsonConfig isn't on NuGet (because I mostly deveop on linux and mac which has trouble working with nuget) and so I think most users add it as a sourcecode repository. I am a big fan of DI Containers, but I don't think we should shove a DI Container down to the user's throat for JsonConfig. |
Btw. I'd love to have Json.NET PCL so that JsonConfig can become PCL compatible (profile 78). |
I agree - while a consumer of the lib might choose to use a DI lib, we can't use one because it will cause nightmares for anyone not using the exact same lib / version / pattern of use as we do. This is my first time working with github (but I used to use and push BitKeeper on people back in 2004, so I'm familiar with the concepts). I'll figure out how to make a pull request from my local branch and then send you one for the compile-time define switch that I have now. |
Created a pull request for the compile time option to use JSON.Net (initial version, not all unit tests pass... they probably won't pass without a change to JSON.Net): |
Until there are failing unit tests I am unsure if and when to merge this. I got some ideas for API breaking changes that will be the next major versions, but I have a lot on my plate and no ETA on this. Failing tests means that shouldn't go into master without changing the API or reworking the tests. |
I'm not sure it will be possible to make all the unit tests pass as the unit tests are very specific to how JsonFx deserializes arrays to the strongest-typed array that it can pick, such as string[]. JSON.Net's ExpandoObjectConverter just creates List for each of these lists, which causes casts in the unit tests to ICollection to fail. I can change the casts to ICollection to get more of them to pass, but that doesn't seem like what we want here. We can create our own version of a JsonConverter, based on the ExpandoObjectConverter in JSON.Net that handles lists differently, but it seems we'd have to take most of the logic from TypeCoercionUtility.cs in JsonFx in order to get JSON.Net to do the same thing as JsonFx, which also doesn't seem right. What do you think the end goal should be:
Advantages: Anyone depending on JsonFx can swap over to JSON.Net without changing their code, in theory. Disadvantages: Developers who have used JSON.Net before will be getting back object types that they might not have expected to get from JSON.Net since we'd be using a custom converter class.
Advantages: Possible to code without having to import JsonFx logic, developers familiar with either parsing lib will understand the object types that they see returned. Disadvantages: Swapping parsing libs will require some small, one-time, code changes. Which do you think we should aim for? I think that requiring knowledge of the parsing lib is ok, but I'd like to know what you think. Harold |
Amazing that so many are thinking the same thing. Any progress on this? |
Why not using a custom converter ?
(shamelessly adapted from DictionaryConverter) Use :
|
Anyone ? |
Is this still happening? I would like to use this lib, but I need json.net |
Hi there, great library.
I've run into a number of problems trying to compile the solution and it is largely due to JsonFX. I was able to get it running on some sites, but others would crash unexpectedly.
I modified your code to use http://www.nuget.org/packages/newtonsoft.json/ which is the most widely and popular used json library in .NET. Now it works without any issues at all.
Just thought you should know, I can provide details on the code I changed if you'd like.
The text was updated successfully, but these errors were encountered: