Automatic deserialize JSON to IContent implementations

[rasmusjp]

This is still a WIP

Added automatic deserialization into custom models as described in #11 (comment)

Right now it works for Document Types but needs to be implemented for Element and Media Types.

[sitereactor]

Changing the return type from Content to IContent would force you to cast it to something else as you would not have access the Properties property, which is not exposed on IContent.

[sitereactor]

I'm wondering if it is necessary to change the return type. For the strongly typed models don't we inherit from Content anyway?
(Just thinking about a possible middle ground ... An alternative could also be to simple provide another set of methods that can return a generic list where the types are "hidden". But then again it might be confusing why you would use one over the other).

[rasmusjp]

The reason for changing it to IContent was that I didn't want to inherit from Content, the reason is that you'll get the Properties dictionary but it'll only contain the "extra" properties that aren't present on the model, which I think might be confusing too

[sitereactor]

Okay, but this also assumes that you are using strongly typed models right? Otherwise it wouldn't really be usable or at a minimum it would force you to cast it to Content.
And its the forced Cast and assumption I'm not to keen on.

Maybe an alternative could be to have GetRoot, GetAnscestors, etc. take a list of types in a method overload, so you essentially tell that you want the root items of types x and y in the returned list of IContent. Then at least its explicit.

[sitereactor]

Something like:

Task<IEnumerable<Content>> GetAncestors(Guid id, string culture = null);
Task<IEnumerable<IContent>> GetAncestors(Guid id, string culture = null, params Type[] modelTypes);

I realize there might be some overload clash here, but just an example. Method name could also be something like GetAncestorsTyped, GetAncestorsAsTypes.

[rasmusjp]

Instead of creating overloads I've gone with the requirement of inheriting from Content, I think that's an okay compromise for now. Will you give it a look before I continue with Media?

[sitereactor]

This would be a breaking change, so maybe consider adding another interface to add the ITypeList<IContent> ContentModelTypes and leave IHeadlessConfiguration untouched.
For the implementation and the public class we could then choose to only expose the one you implemented in HeadlessConfiguration.

We'd of course need to check on ContentModelTypes, so we can pass an empty list, but think that would be okay.

[sitereactor]

oh, and since ContentDelivery is internal we should be able to change the constructor so we can change the interface that is passed in.

[sitereactor]

I think this will work fine. Having to inherit from Content is an okay alternative. Of course you get the Properties property as part of the object, but it gives a bit more flexibility in terms of types for those that want it.
I'm unsure though, if the Properties property on Content will still be populated with values when using a strongly typed model with a different set of properties

One thing that we will need to ensure before this is released is that it still works with Xamarin (UWP, Xamarin.Android, Xamarin.iOS). There are some limitations around reflection, so just want to ensure that we don't inadvertently break compatibility.

[rasmusjp]

Properties will only be populated with values that cannot mapped, so if a property exist on the model it's value won't be available in Properties.

Regarding UWP and Xamarin we should be good, as far as I can see it's Relection.Emit and Reflection over private members that isn't allowed (see https://docs.microsoft.com/en-us/dotnet/framework/net-native/reflection-and-net-native and https://docs.microsoft.com/en-us/xamarin/ios/internals/limitations)

[rasmusjp]

This is ready for review now.

I've added a new interface IStronglyTypedHeadlessConfiguration (not sure about the name) which contains 3 properties ElementModelTypes, ContentModelTypes and MediaModelTypes where the strongly typed models can be registered. An example can be found in the .NET Core MVC sample, Image, File and Folder are registered by default for media if you use any of the default configuration classes.

The (content/media) type alias that is used to lookup the model types based on the class name, this can be overwritten by adding one of the following attributes to the model, ElementModelAttribute, ContentModelAttribute or MediaModelAttribute

[NiclasLindqvist]

This looks great, seems to be working as intended from what I've seen so far! 👍 Is there any possibility to allow "casting" to PagedContent<T>. e.g. when using GetChildren (where using GetChildren<T> is possible) or when using Filter (where no Filter<T> is available)

If it was possible to call something like the following, that'd be very helpful!

var filters = new List<ContentFilterProperties>() {
    new ContentFilterProperties("property", "value", ContentFilterMatch.Contains))
};
var contentFilter = new ContentFilter("thing", filters.ToArray());
var items = (PagedContent<Thing>) await _contentDelivery.Content.Filter(contentFilter);

[NiclasLindqvist]

The above mentioned was somewhat resolved by #19 as you can now do both GetChildren<T> and Filter<T>. Adding support for Search<T> would possibly be useful as well, however it is hard to guarantee the result from such a rudimentary search is only of the requested type I suppose.

[rasmusjp]

I've rebased and updated the code.

I've opened a new PR with a Xamarin Forms demo #31 we can use to test that the library is still working with Xamarin