Hi David

No, currently this won't be mapped by convention.  I'm assuming you have a complex type on your view model looking something like this:

    public class MainModel
    {
        public string Foo { get; set; }

        public SubModel Bar { get; set; }
    }

    public class SubModel
    {
        public string Baz { get; set; }
    }

And that you have a document type that's to be mapped to MainModel that has a content picker on it, the content for which you want to map to the Bar property of type SubModel.

You could do this by creating a custom mapper for objects of type SubModel as you have, but there's a couple perhaps easier ways.

1) would be to just make a second mapping call like this:

    var vm = new MainModel();
    Mapper.Map(CurrentPage, vm)
        .Map(CurrentPage.GetPropertyValue("bar"), vm.Bar);

You'd also in this case need to amend your view model such that the SubModel property value is not null when an instance of MainModel is instantiated:

    public class MainModel
    {
        public MainModel()
        {
            Bar = new SubModel();
        }
        
        public string Foo { get; set; }

        public SubModel Bar{ get; set; }
    }

Or 2) you could collapse your view model to look like this and use a mapping attribute to tell it to have it's content mapped from a property on the related content.  More on this here.

    public class MainModel
    {
        public string Foo { get; set; }

        [PropertyMapping(SourceRelatedProperty = "baz")]
        public string Bar { get; set; }
    }

---

Having said all that, you've got me thinking that maybe what we're doing in the examples above could just be a convention.  If you have a view model with a complex type with a name matching a property on your document type which is a content picker, and that complex type has a property with a name matching a field on the picked content, it could just map that.  Will give it some thought though might not be a good idea simply around performance - having to test to see if a given field is IPublishedContent rather than relying as we currently do on the developer indicating that it is in the mapping operation or the attributes.

---

And if you could let me know where you are reading that from the documentation please, as could be I need to clarify something.  Just to confirm too, by "Property Editors project" you mean this one I'm assuming?

Hope that helps

Andy

Oh, and on the related question, no, you'll still need a custom mapper.  If though as you have created a property value converter that creates an instance of the complex type you are using on your view model, it would be very thin, something like:

  public static object GetCustomModel(IUmbracoMapper mapper, IPublishedContent contentToMapFrom, string propertyName, bool recursive)
  {
    return contentToMapFrom.GetPropertyValue<MyCustomModel>(propertyName, recursive);
  }

Ok, thanks. That's pretty clear.

I was talking about the same property editor project.

I've got a singleton that contains the Mapper, and is setup with all the CustomMappings (implementations of IPropertyEditorValueConverter) that I can find on application start. I'm not seeing any performance issues working with it this way. Presumably if I actually wanted an int rather than an IPublishedContent, for some form of Lazy loading, then I'd just make sure my property was of type int.

I think I'd misunderstood the first paragraph 'Further Property Mapping Overrides' of the GitHub readme to suggest that an IPublishedContent would be returned, but that doesn't quite fit with the code example directly above so it's probably just my error.

is working on a reply...