Is it possible to automatically populate a SystemProperties property in a POCO class?

[deanebarker]

I have a POCO class called Term. It is populating as expected.

Can I get a SystemProperties object populated? I'd like to do something like this:

public string Title { get; set; }
public string Body { get; set; }
public SystemProperties Sys { get; set; }

As I'm sure you're aware, this doesn't populate (Sys remains null). I know that I could do Entry<Term> to get this, but how reasonable is it to expect the API to reflect the existence of a SystemProperties property, and automatically populate that?

[Roblinde]

At the moment this isn't possible, but I understand that this would be convenient. I'm planning on adding some more serialization magic to the GetEntry-methods that would allow for this. Possibly you'd have to implement an interface, but I'm hoping that wouldn't be necessary, simply checking for the existence of a SystemProperties field via reflection should be enough.

[Roblinde]

Proposed solution (mostly so that I remember it myself...): Add the sys property as part of the fields structure before deserializing. That way any serialization attributes added to your POCO class would be respected and you could use custom serialization techniques like json converters or similar.

This would also make sure you don't have to add any custom interface or anything. Just a plain class.

[Roblinde]

This is now added in 0.5.2-alpha.

Documentation will be updated as soon as I get the time.

[deanebarker]

Geez, took you long enough. I expect more responsiveness from you guys... :-)

[deanebarker]

FYI -- I'm not seeing a 0.5.2-alpha out on Nuget. It doesn't show up as an update.

[Roblinde]

It's unlisted still, I think you need to manually install it through the package manager console. Let me know if it doesn't work.

[deanebarker]

Got it. I updated, and it works as expected.

To anyone else looking at this issue in the future: the SystemProperties property has to be named Sys. It's deserialized like any other field, so it's specifically matching on the Sys property name, not the fact that it is of type SystemProperties, which you might expect.

[Roblinde]

A small addition. The property could actually be named anything, but you would have to decorate it with an JsonProperty attribute to let the serialization engine know how to serialize.

Like this:

 public class Term {
      [JsonProperty("sys")]
      public SystemProperties NotSys { get; set; }
 }

Also not in the documentation yet 😞 . Will be adding a serialization / deserialization section sometime soonish.

[deanebarker]

There's always an interesting question of how to delineate the difference between (1) something that is specific to your API, and (2) something that is inherited from an "upstream" API (Newtonsoft JSON serialization, in this instance).

The OnDeserialized thing from #4 is another example -- from my reading, that's not your thing, that's core to the framework, and probably being called from the Newtonsoft library.

The trick is when people start to think you're just an overlay on top of a something upstream, then they start to depend on that upstream API's doc and capabilities, which gets tricky when you do things to change them, or even swap the upstream API out altogether.

[Roblinde]

Yeah, I agree, the serialization section would mostly be a pointer to the Json.Net documentations, but some "best practices" examples would be nice to have. The OnDeserialized attribute is actually a framework thing, but Json.Net implements it.

[deanebarker]

When you come up with a more comprehensive event model, perhaps it would make sense to have events that overlap on those attributes, then steer people towards using the events for consistency and flexibility in the future. Clearly, you can't stop people from using OnDeserialized, but you can provide a better overall model and make it clear that it's "more canonical," supported, and resilient to future changes.