Override Xml Serialization

[hcoverlambda]

Is there a way to override xml de/serialization? We need to have some control over datetime de/serialization (For ISO 8601) so we're looking to hook into with our customization's. It looks like the only place it would be possible to do that is to swap out XmlFormatter with our own, which would give us what we want, but I'm not seeing how to do that. With json we are just doing a ReplaceService<IJsonReader/IJsonWriter, MyFunkyJsonWhatever>() but that's obviously not going to work with IFormatter.

[Mike O'Brien]

Oh duh! I guess I can just do an AddService<>(). I just noticed that the formatter says what mimetypes it can handle. So I guess my question now is how can I remove/replace just the XmlFormatter? Is there a way to remove/replace a service by it's concrete type?

On Fri, Nov 16, 2012 at 2:04 PM, hcoverlambda <m...@mikeobrien.net> wrote:

Is there a way to override xml de/serialization? We need to have some control over datetime de/serialization (For ISO 8601) so we're looking to hook into with our customization's. It looks like the only place it would be possible to do that is to swap out XmlFormatter with our own, which would give us what we want, but I'm not seeing how to do that. With json we are just doing a ReplaceService<IJsonReader/IJsonWriter, MyFunkyJsonWhatever>() but that's obviously not going to work with IFormatter.

--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/vhnlsdKlWWAJ.
To post to this group, send email to fubumv...@googlegroups.com.
To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.

[hcoverlambda]

So I'm on the latest bits and I'm back to this issue. In the new bits, what would be the best way to override the both xml and json serialization and deserialization. I'm looking at the code under FubuMVC.Core.Resources.Conneg and there are a number of moving parts so I'm at a loss on how to accomplish this. In the policy DSL there is a section for manipulating the writers but not the readers which was a little confusing. Also, I would love to be able to do the deserialization in some sort of chained manner and it looks like that might be possible with ReaderChain? 

TIA,

m

To unsubscribe from this group, send email to fubumvc-devel+unsubscribe@googlegroups.com.

[Jeremy D. Miller]

Mike,

Everything you can do with the writers you can also do with the Readers on BehaviorChain.Input.

What exactly is confusing?  When you say that you're customizing the serialization, in what way exactly?

I'm happy to consider changing the XmlFormatter to make this easier based on usage.

To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/BcDLL3M1fs0J.

To post to this group, send email to fubumv...@googlegroups.com.

To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.

[Mike O'Brien]

Yeah, I was thinking that you had to do it through Policies.Add(x => x.Conneg.AddWriter<...>()) but you're saying you can just go through Policies.Add(x => x.ModifyBy(x => x.Input...)). That was what was confusing me, I think I get it now. I haven't done a whole lot with modifying the behavior chain other than wrapping behaviors so this is a little new to me.

On the serialization:

First, I need to customize how DateTime's and enum's are de/serialized for both xml and json. We need to have DateTime's be ISO 8601 (Supporting UTC) and enum's to be the string representation. There are some quirks with both serializers that cause some inconsistencies in our API. 

Second, we have some custom binding that we do. I currently have a little reader "behavior chain" setup (Not a fubu one) that lets us pass the incoming json through a couple of reader behaviors. The reader "behavior" decides if it can deserialize it or not and if so handles it and passes the input model. We have default reader "behavior" that just does the normal deserialization if the custom ones don't handle it. The reason we are doing it at this point is we are potentially deserializing the json request to a type other than the input type. That's why the ReaderChain piqued my interest, looked similar to what we were doing at first glance. But there may be a better way to do this, no idea.

[Jeremy D. Miller]

Ok, so you've got a couple options:

On the json front, you can use the FubuMVC.Json package to get Json.Net in place of the OOTB serializer and customize how Json.Net does its business -- or honestly, it's not very hard to just drop Json.Net in w/o the Bottle

You *could* check out FubuMVC.Media's projection support to get far better control over how you render to json or xml

You could bypass the build in formatters and just create your own Reader's and Writer's and attach those to the Chain.Input and Chain.Output nodes

One way or another, the BehaviorGraph/BehaviorChain model is *everything* in the application.  The FubuRegistry DSL is just some short hand ways to perform common alterations to the BehaviorGraph, but you can always drop down to the metal to do more than the DSL allows.

[Mike O'Brien]

Oh yeah, forgot about the projection stuff. Josh had mentioned that a while ago. I'll give it a look.

Thanks for the suggestions!

[Jeremy D. Miller]

Without seeing what your code is, I don't know if that'd be more or less work for you -- but definitely much more control than you'd get from any serializer tool.

[Mike O'Brien]

This is weird, the XmlFormatter just deserializes the xml and passes back the model, but the JavaScriptJsonReader (Which is taken into the JsonFormatter for deserialization) also binds request properties. Seems like either models deserialized from xml will not have those bound (Because it should happen at the formatter level) or models deserialized from json are being bound twice (Because its also happening again at a higher level).

[Mike O'Brien]

Oh yeah, reason I'm asking is I'm wondering if I need to include the request property binding if I roll my own IFormatter (As it is in JsonReader) or if its taken care of at a higher level. The fact that its done in one formatter and not the other was confusing.

[Jeremy D Miller]

Hey Mike, do you wanna hook up via Skype tomorrow to talk over this?

Sent from my iPhone

[Mike O'Brien]

If you have time that would be awesome. I'm totally open after 11 am EST.