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:
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. :)
- 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