Well, I succeeded in the FlexJSON port, although the resulting code is still a bit.. um. Shall we say, suboptimal. However, I did get the most relevant bit, which is the idea behind the path expressions.
Ok, I guess I could have come up with the same idea myself, but what the hey, I enjoyed the work. I’m now working on implementing the same idea from scratch with a few modifications. The include/exclude patterns in FlexJSON aren’t quite as powerful as I’d like them to be, so my implementation will have a way to determine the most specific of two patterns, the basic rules being:
- A longer pattern will always win over a shorter one
- In patterns of equal length, the one that contains the first wildcard loses
- and if all else fails, Include always trumps Exclude
This should leave me with a way to control serialization in a relatively succinct way, and lucky me, I’ve even got a bunch of real-life test scenarios to try them out on.
Another idea I’m toying with is transformers, also stolen from FlexJSON. In addition to path-based transforming, I thought I could include attribute- or type-based transforming and filtering — depends a lot on which turns out to be the most useful.
The way I’m thinking is I could have an attribute on a class or a property that is in no way tied to the JSON serializer, but I could still use it to control serialization by way of the transformer. The transformer would be a delegate, which comes with some nice implications, such as being able to easily refer to the current user of the web app (since the delegate can be an instance method on the controller) without making the serializer aware of the fact that there even is a web app. Crazy? Genius? You decide.
Oh, I’m also at this point determined to patch this stuff on top of Json.NET.
I guess it’s time to try and quit thinking about work and concentrate on having a beer, though.
While on the lookout for a JSON serializer that would allow me to include or exclude parts on a per-serialization basis instead of just per-class basis (which is what Json.NET gives me), I ran into FlexJSON. Unfortunately, it’s for Java, and I’m working in C#. What’s a programmer to do?
Well duh, port it, of course! What better way to learn the ins and outs of the library?
I hacked on the sources for about three hours today. I started out by changing all the file extensions from .java to .cs, then opening the things in VS.Net and pretty much mechanically changing the incompatible bits, accessors to properties and whatnot. Surprisingly little effort there — the Java and .NET reflection classes are very much alike.
I haven’t had the time to understand all of the code properly yet, for example I still need to figure out what the deal is with the chained set and iterator thing. I suspect it has to do with avoiding reference loops in object graphs.
I’m not sure whether or not this will ever be finished, but I’m going to give it some more time tomorrow. I’m hoping to get it to a point where I can start running the test cases and see what breaks.
If I should be so lucky as to actually get this thing done, I think I’ll try to wrangle a permission to publish the port. What I’d really like to see, though, is this feature in Json.NET since that’s what I’m currently using and from what I gather, it also ships with MonoRail these days. Tomorrow I’ll probably have a better idea of what it would take to add the feature. No promises though.
Edit: Json.NET does support the feature I’m looking for after a fashion — but I gather that I’d have to walk the object graph myself. So basically grafting on something similar to the FlexJSON path expressions might just do the trick.
It’s been a while since I abandoned my previous blog. I did it for a couple of reasons. First, I’d really like to focus more on software development and my experiences in it than the rest of my life, and second, keeping WordPress up to date was really getting on my nerves. I do like to express myself in writing, though, so I thought I’d give it another shot. I have a couple of topics on my mind already.