umco / umbraco-ditto Goto Github PK

How about a resolver to get a value from appSettings (in web.config) ?

In the context of the converting / converted events, does use of the word "convert" make sense, or should we use something more like "map"? or are these so similar it doesn't make much difference?

Looking at the unit-tests durations on a recent AppVeyor build...

https://ci.appveyor.com/project/leekelleher/umbraco-ditto/build/0.8.0.320/tests

...some of the unit-tests take a while to run. I had a cursory check of the longer duration tests, and the models that are used in those tests are using some form of custom ValueResolver.

The 2 longer running ones are:

• AppSettingsTests.AppSetting_Property_Returned() - uses AppSettingValueResolver
• PublishedContentTests.Complex_Property_Convertered() - uses an ad-hoc one called NameValueResovler (sic)

Currently this is still a gut feeling, but I wanted to flag it on here.

Following up on comments from here:

c764b2a#commitcomment-11501134

if a POCO has a nullable DateTime? property and the value to convert is empty or not set, the POCO property value is set to DateTime.MinValue.

Hey all,
As discussed on the forum, It'd be nice reuse the functionality of UmbracoPropertyAttribute when using writing new value resolvers. For example converting an existing property into a different value (eg. IEnumerable<IPublishedContent> to a single IPublishContent.

As this isn't already in the core, Lee outlined this line would need to change.

Thanks,
Jamie

Hey Dudes,

This is a follow on to the discussion in regards to #97. I'm obviously jesting in the title of this post, but the more I am using Ditto, with the additions of ValueResolvers, I find myself questioning if TypeConverters and ValueResolvers are both completing the same requirement in differing ways.

I have written a couple of extensions to Ditto for Archetype and Grid binding and the more I use ValueResolvers the more I feel the usage is cleaner, with a lower barrier to use. They also appear to be able to not only complete the task of TypeConverter, but take it a step further by binding values where you have no property to get data from. Best of both worlds really. In saying that, I totally get that TypeConverters are the recommended method in .Net for TypeConversion (obv) so can see how this has its place.

So yeah, just thought I'd mention this observation. I may be missing something along the caching or perfromance line with TypeConverters and if I am then send me back to my corner. Plus I realise this is a pretty fundamental part of the implementation so would not be insignificant, just wondered on you guys two cents on this after reading the above post.

Peace.

Wonder if we should add an "invert" attribute on the UmbracoPropertyAttribute to allow you to invert a boolean. For example, say you have a "Hide" checkbox on a doctype, but in your viewmodel you want the property to be IsVisible, we could just flag this to invert and have the resolver handle the switch?

The only issue being it only really applies to booleans, so is pretty useless for every other property value type.

Right now, if you have a value that needs to be populated from multiple fields within an IPublishedContent we have 2 options. One is to pass in a func to the .As call, and the other is to register an event handler and detect that type being converted.

The problem with the first option is that it requires you to be in control of the .As call, which may not be the case (such as in DitFlo), and the problem with the event handler is that it moves the logic of populating the calculated values away into a "hidden" place, ie, it's not very discoverable.

Whilst looking into how JSON.NET handles similar things, I came across the OnDesrializedAttribute and thought, what if we added a [DittoOnConverted] attribute to allow people to populate these calculated properties more easily.

Now, I have two possible implementations of this attribute, on a method or on the class (or both).

On a method

public class CalculatedModel
{
    public string Name { get; set; }

    [DittoIgnore]
    public string AltText { get; set; }

    [DittoOnConverted]
    internal void OnConverted(ConvertedTypeEventArgs e)
    {
        AltText = e.Content.GetPropertyValue("siteName", true) + " " +
            e.Content.GetPropertyValue("siteDescription", true);
    }
}

This would be the same as the OnDeserializedAttribute referenced above. With this, we define one or more methods to call on the entity after the entity is converted. The plus side of this is that the logic for populating the calculated properties is kept with the model itself. The downside is, it means you now have logic inside you POCO's..

On the class

[DittoOnConverted(typeof(CalculatedModelOnConvertedHandler))]
public class CalculatedModel
{
    public string Name { get; set; }

    [DittoIgnore]
    public string AltText { get; set; }
}

public class CalculatedModelOnConvertedHandler : DittoOnConvertedHandler<CalculatedModel>
{
    public void OnConverted(ConvertedTypeEventArgs e){
        Model.AltText = e.Content.GetPropertyValue("siteName", true) + " " +
            e.Content.GetPropertyValue("siteDescription", true);
    }
}

When registered on the class, we could have it reference a Type for a DittoOnConvertedHandler which can just have a single function to populate the model variables. The pro of this is that it keeps your poco's pocos, but it's a bit more work to setup and requires extra classes to be setup.

Now, we could also just implement both so people have options as we could just detect it on a method or on a class and have it trigger the different options based upon it's usage.

What do people think?

(Feature sparked from discussion in #77)

Let's explore the idea of having Ditto re-apply the IPublishedContent from a POCO on one of it's own properties.

An example with code would be...

public class MyModel
{
    [DittoReapplyContent]
    public MyOtherModel MyProperty { get; set; }
}

Obviously DittoReapplyContent is an absolutely terrible name... suggestion welcome!

This would be the equivalent of doing: foo.MyProperty = content.As<MyOtherModel>().

It looks more explicit in code when using ditto event handlers

This pertains to Umbraco 7.2.4 and Ditto 0.6.1

Hello! I've been playing with integrating Ditto into a test project and ran into an issue when using the MultiNodeTreePickerConverter: it would throw when passed an empty string, which I believe happens when the user hadn't selected any content.

public class Event : BasePage
 {
    public Event(IPublishedContent content) : base(content)
    {
    }

    public DateTime StartTime { get; set; }
    public DateTime EndTime { get; set; }
    public string EventName { get; set; }
    public string EventDescription { get; set; }

    [TypeConverter(typeof(MultiNodeTreePickerConverter<Location>))]
    [UmbracoProperty("location")]
    public IEnumerable<Location> Locations { get; set; }
}

I would get a NotSupported exception if the user didn't select any locations in the back office.

I fixed it by subclassing:

public class AllowEmptyMultiNodeTreePickerConverter<T> : MultiNodeTreePickerConverter<T> where T:class
{
    public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
    {
        if (value is string && value.Equals(""))
        {
            return Enumerable.Empty<T>();
        }

        return base.ConvertFrom(context, culture, value);
    }
}

And using that type as the TypeConverter in the attribute.

Looking at the code, MultiNodeTreePickerConverter returns an empty enumerable if passed a null to convert.

Am I using this attribute incorrectly?

If not, I was wondering if you were interested in a PR that treated empty string the same?

Thanks for your time!

I have a simple document type 'Home' which has no properties and I've included a 'LanndPageHeading' document type which defines a single property "headline" which does not appear to be mapped by Ditto.

I'm using the DittoPublishedContentModelFactory

Latest version from NuGet.

Since the global DittoEventHandlers have been removed, would we be able to a custom DittoConversionHandler for a model-type, (at app-startup), so that we can manipulate the object post-conversion.

A proposed example would be:

DittoConversionHandler.RegisterHandler<MyModel, MyModelConversionHandler>();

Support for Umbraco Relations was originally raised in #36, but got lost in an evolving discussion.

The new DittoValueResolver approach can be used to easily support Relations.

if a dictionary key, or an app setting key aren't provided with their corresponding attribute, then fall-back to using the property name

Review the exception message for when an object/type has invalid constructor parameters.

40a41d2#diff-81cfd4fcb771a0cad63163155354443cR290

Hi,

Getting this error on a clean install all setup with nuget - so new mvc app, new umbraco site and then installed ditto and ditto PCM packages using Nuget.

Method not found: 'System.Object Our.Umbraco.Ditto.PublishedContentExtensions.As(Umbraco.Core.Models.IPublishedContent, System.Type, System.Action1<Our.Umbraco.Ditto.ConvertingTypeEventArgs>, System.Action1<Our.Umbraco.Ditto.ConvertedTypeEventArgs>, System.Globalization.CultureInfo)'.

I have tried doing an As in the view but get same issue above as when trying to use PCM published content model)

I have also added the PCM init class.

What am i missing? Or is there an issue?

I'm wondering if we could do a Ditto.Compat project for v6? A lot of agencies I know are still using that major version.

I have a load of code written already that will allow v6 support for type conversion and run a custom version of the project that used conditional compilation to spit out the correct code using #if

Obviously there are issues with using the built in generic methods like Ancestors<T> since we have no PublishedContentFactory but as far as I'm aware that affects v7 also if the factory is not used. Am I correct in that assumption?

I have a base class that contains strong typed equivalents for those methods e.g. GetAncestors<T> just now. I wonder whether we can simply give it the same name... There might be ambiguous reference issues though.

We would have to use PublishedContentExtended rather than PublishedContentModel for any inheritance but thats not an issue.

What are your thoughts?

Currently the only "documentation" is the README, which has turned into a massive wall of text!

Look at moving over to using GitHub Pages (on a gh-pages branch) in future.

Following a chat with @Hendy I've come to realise that we don't actually need the <T> type parameters on the TypeConverters we have them on any more since we pass the PropertyDescriptor within our context.

I guess that was the original intent @Hendy yeah?

We can use context.PropertyDescriptor.ComponentType to get the parent class and property type context.PropertyDescriptor.PropertyType and the
As(this IPublishedContent content,Type type...) extension to process that type.

This would make using the built in converters a lot less verbose.

Now obviously this is a breaking change so that's why I've raised this for discussion.

I quite like the idea of the user simple not caring about stuff like that since we have already dealt with it but I appreciate also that this will cause existing code to require updating and make our codebase a little bit more complicated.

What do you think?

I'd like to suggest that we remove the Ditto.ModelFactory code from the main Ditto repository.

Original the Ditto.ModelFactory code was a proof-of-concept, rather than a recommended approach.

Recently it has felt more of a burden having it part of the main Ditto release-cycle.

I'm not suggesting that we nuke from orbit, instead we can move it to my 🆕 Ditto Labs spin-off repository.

Open for comments... 😻

@Hendy mentioned this in the Gitter chatroom.

Consider adding support for Relations.

[RelationType("relationTypeAlias")]
public object RelatedItems { get; set; }

Then Ditto could get the related node IDs for the associated IPublishedContent node and pass the value to the POCO property.

e.g. @Model.RelatedItems could return a IEnumerable<IRelation> object type?

Details of the IRelation interface can be found here.

Then for more complex types a custom TypeConverter can be used:

[RelationType("relationTypeAlias")]
[TypeConverter(typeof(RelationsTypeConverter))]
public IEnumerable<IPublishedContent> RelatedItems { get; set; }

Then the custom RelationsTypeConverter can work out how to convert an IEnumerable<IRelation> into IEnumerable<IPublishedContent>.

This is a general open question about how could we unit-test Ditto.

Initially I thought about unit-testing the built-in TypeConverters, but I think we'll hit issues with the UmbracoHelper context.

Still worth a discussion.

Following up on a discussion over on nuPickers issue #100, I had a thought about having a ValueResolver that would return an Umbraco properties raw value.

The idea would be that it would bypass any IPropertyValueConverters for that property-editor's value.

The resolver itself would be similar to UmbracoPropertyValueResolver, but with a small change, see #L36

Instead of...

content.GetPropertyValue(umbracoPropertyName, recursive);

... we'd have...

content.GetProperty(umbracoPropertyName, recursive).DataValue

The use-case here, for example, would be when using nuPickers - it would typically return a Picker object, but the underlying (raw data) value would typically be a CSV of content node IDs.

To note, with nuPickers you can have other data formats, (CSV, XML, JSON), so it's not super straight-forward... but if you are the developer of the project, then you can configure this be CSV and work nicely with Ditto.

Any thoughts?

On one of my websites, I'd like to aggregate the values from a recursive Umbraco property, so rather than use recursive as a fall-back value, I can bundle all the values together.

An example (that I'm currently using) is that of additional HTML meta-tags, e.g. each page/subpage has it's own unique value which would need to be displayed/rendered.

The POCO's property would be like this...

public IEnumerable<HtmlString> HtmlMetaTags { get; set; }

Currently I am hooking into the post conversion code to manually populate the property...

foo.HtmlMetaTags = content.AncestorsOrSelf()
    .Reverse()
    .Where(x => x.HasValue("htmlMetaTags"))
    .Select(x => x.GetPropertyValue<HtmlString>("htmlMetaTags"));

I'm wondering if there is a way to wire this up using a custom ValueResolver (and/or inheriting from the UmbracoPropertyAttribute)?

Then discuss whether this could be a potential addition to the Ditto core.

What would you say was best practice for Ditto in relation to the models? To use inheritance to match the document types or to have each doctype as a single POCO and have properties for the other POCOS. For example DType.SEO.MetaDescription

I have done a biggish project before with the PublishedContentModel and used inheritance and you had to keep your inheritance structure this in sync with the DocTypes - but was more efficient dev wise not having to bash out all the properties on each POCO but just the new ones that weren't inherited.

What would you recommend? Is there any performance advantage over each option?

I'm trying to cast a property As RelatedLinks (the core property) but I'm getting the following:

Can't convert IPublishedContent to Our.Umbraco.PropertyConverters.Models.RelatedLinks as it has no valid constructor. A valid constructor is either an empty one, or one accepting a single IPublishedContent parameter.

Simply using Our.Umbraco.PropertyConverter on the value works fine but when trying to pass it through a DittoValueResolver, I get the above exception. I have a simple workaround but just thought I'd let you know.

Hi guys

Not even sure if this has anything to do with Ditto, but here goes.

Been testing Ditto on a new project where I use Autofac to do some basic dependency injection.
However, I found, that as soon as I set the AutofacDependencyResolver as the current DependencyResolver type converters will simply stop running. Disabling DI will make everything work again. I've zip'ed a complete solution if you guys wan't to take a look -> https://dl.dropboxusercontent.com/u/3371537/NestedDittoDemo.zip

There is a single page using the Nested Content data type which again contains a multinodetreepicker. If you look in App_Code/Start.cs you can see the Autofac configuration I use. Take a look at Views/Page.cshtml for the code that is using Nested Content and Ditto.

Hopefully it's fairly straight forward to see whats going on, if not, let me know :)

Cheers
Mads

Consider caching the reflected objects.

We haven't looked into the performance of the reflection calls (e.g. GetConstructors or GetProperties), could it be improved?

Maybe a dictionary lookup instance?

var cache = new Dictionary<Type, PropertyInfo[]>();

Following on from the PR #44 - Adding archetype support to Ditto, let's look at ways that we can support mapping Archetype (without modifying the Ditto core).

There are situations where we want Ditto to ignore a property and not attempt to map it with an Umbraco property.

Currently we can do a hack where we can assign a fake property alias, e.g.

[UmbracoProperty("fakePropertyAlias")]
public string SomeOtherProperty { get; set; }

but it feels too much like a hack; when we know our sentiment is to ignore the mapping.

Hi, if a value is null, it seems that TypeConverters aren't called, running a TypeConverter on a null value could be useful to set a default fall-back value (for when something hasn't been selected in the cms)

In RenderModelExtensions.cs there is a restriction on the extension method that limits the return type T to implementations of RenderModel.

Is that correct? It seems to me too restrictive since we are operating on the Content property. I assumed that this method was just a short-cut to IPublishedContent.As<T>

When building against a fresh install of Umbraco 7.2.1 (with no other packages installed) Visual Studio warns:

_"1>C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed."_

The conflicting assemblies might be System.Web.Mvc and Umbraco?

So in my DitFlo demo, I've been making use of ValueResovlers a lot to resovle view model properties. There comes a time though when the value depends on certain flags within the request. Now we could have the value resovler just access the request, or we can DittoIgnore the property and we construct the value ourselves within a controller, however I was wondering if the concept of a ValueResovlerContext, that can be set at runtime, could be a handy feature.

In the DitFlo demo we have a news listing page that lists news items in a paged manor. To get the news items I'm using a value resovler, but obviously, the value resolver needs to know the current page so that it can grab the right news items.

This is my current implementation which directly accesses the HttpContext Request object is as follows:

public class NewsResolver : BaseNewsResolver
{
    public override object ResolveValue()
    {
        var currentPage = long.Parse("0" + HttpContext.Current.Request["p"]);
        var pageSize = 2;

        var items = GetNews().ToList();
        var totalItems = items.Count;
        var totalPages = (long)Math.Ceiling(totalItems/(decimal)pageSize);

        currentPage = Math.Max(1, Math.Min(currentPage, totalPages));

        var pagedItems = items.Skip((int)(currentPage-1)*pageSize).Take(pageSize)
            .As<NewsPreviewLink>();

        return new PagedCollection<NewsPreviewLink>
        {
            CurrentPage = currentPage,
            PageSize = pageSize,
            TotalItems = totalItems,
            TotalPages = totalPages,
            Items = pagedItems
        };
    }
}

However from discussions held here https://github.com/mattbrailsford/umbraco-ditflo/issues/1#issuecomment-113080492 I've come up with a possible solution using ValueResolverContexts that could make that as follows

Controller

public class NewsOverviewController : DitFloController {
    public ActionResult Index(RenderModel model, int p) {
        Ditto.RegisterResolverContext(new NewsResolverContext{
            CurrentPage = p
        };
        return CurrentView();
    }
}

Resolver

public class NewsResolver : BaseNewsResolver
{
    private NewsResolverContext _context;

    public NewsResolver()
        : this(new NewsResolverContext())
    { }

    public NewsResolver(NewsResolverContext ctx)
    {
        _context = ctx;
    }

    public override object ResolveValue()
    {
        var currentPage = _context.CurrentPage;
        var pageSize = 2;

        var items = GetNews().ToList();
        var totalItems = items.Count;
        var totalPages = (long)Math.Ceiling(totalItems/(decimal)pageSize);

        currentPage = Math.Max(1, Math.Min(currentPage, totalPages));

        var pagedItems = items.Skip((int)(currentPage-1)*pageSize).Take(pageSize)
            .As<NewsPreviewLink>();

        return new PagedCollection<NewsPreviewLink>
        {
            CurrentPage = currentPage,
            PageSize = pageSize,
            TotalItems = totalItems,
            TotalPages = totalPages,
            Items = pagedItems
        };
    }
}

public class NewsResolverContext : DittoValueResovlerContext
{
    public int CurrentPage { get; set; }

    public NewsResolverContext()
    {
        CurrentPage = 1;
    }
}

The idea being that when Ditto resolves the value, it looks for a constructor on the resolver that accepts a context, and if it finds one, look to see if an exact type match has been registered during the current request and if it has, construct the resolver passing in the context.

The main purpose of this is basically decouple the resolver from having to know where to fetch these values from. The controller looks them up and stores them, then ditto handles creating the model and passing them,

Thoughts?

Consider the ability to map Umbraco dictionary items to POCO properties.

e.g.

[UmbracoDictionaryItem("MyLabel")]
public string SomeLabel { get; set; }

Also wondering whether UmbracoPropertyAttribute should support dictionary items (as a fallback), e.g. prefix with a hash [UmbracoProperty("myPropertyLabelAlias", "#MyLabel")]

I've been thinking about Ditto's branding... the Pokemon thing started as a joke, which we've far out grown now 😉

@mattbrailsford Do you have any ideas for a logo similar to your DTGE/NC logos - black circle with nice logo (not sure if you used the Noun Project previously?)

@JimBobSquarePants I've been playing with some CSS for the Ditto name - take a look...

https://jsfiddle.net/leekelleher/uqtc2k3k/

... do you know wide support is for text-shadow?

Totally open for suggestions, etc 😎

A question was raised on the forum about how Ditto maps with the ImageCropper data:

https://our.umbraco.org/projects/developer-tools/ditto/ditto-feedback/66353-imagecropper-mapping-with-ditto

Currently I have no idea, but wanted to flag it up here so we can try it out.

When a model returns a single string property, and a custom TypeConverter also returns a single string, an error occurs within Ditto at:

https://github.com/leekelleher/umbraco-ditto/blob/develop/src/Our.Umbraco.Ditto/Extensions/PublishedContentExtensions.cs#L466

with:
Object of type 'System.String' cannot be converted to type 'System.Collections.Generic.IEnumerable`1[System.String]'.

I'm trying to render a macro in a richtext editor, and it fails in the frontend.

If i disable Ditto i renders fine.

Umbraco: 7.2.4
Ditto: newest from source.

YSOD

Should we move the "Attributes" folder under the "ComponentModel" folder?

It keeps the grouping together with the other component types, (ConversionHandlers, TypeConverters and ValueResolvers)

Hi, wondering if it would be possible to have multiple type converter attributes applied to a property, and have them executed in order ?

For example, may be useful to have a more generic type converter first: saved value to IEnumerable<IPublishedContent> and then a more specific type converter to be executed after converting the IEnumerable<IPublishedContent> to IEnumerable<ProjectSpecificPOCO>

[RelationsTypeConverter("exampleRelationTypeAlias")] // (supplies param to RelationsTypeConverter)
[TypeConverter(typeof(RelationsTypeConverter)]    
[TypeConverter(typeof(ProjectSpecificTypeConverter))]
public IEnumerable<MyPoco> MyPocos { get; set; }

I was asked a question today which I couldn't provide a clear answer to.

What is the difference between a ValueResolver and a TypeConverter?

Looking through conversations here I'm seeing more and more use of ValueResolvers to provide values for the POCO's properties which to me has gone awry from their original intent.

It used to be fairly clear cut when there was one resolver but now much less so for me.

So what is the difference? When should you use a resolver and when a converter?

Im getting a YSOD error on "Save and Publish" after adding a macro into the RTE. (I've tried on a couple of sites with basic macros and it seems to be related to Ditto).

When I remove the following AppStartup code, the error goes away.

public class AppStartup : ApplicationEventHandler {
    protected override void ApplicationStarting(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext) {
        //Add ditto factory
        var types = PluginManager.Current.ResolveTypes<PublishedContentModel>();
        var factory = new DittoPublishedContentModelFactory(types);
        PublishedContentModelFactoryResolver.Current.SetFactory(factory);
    }
}

This is the YSOD error:

Failed to retrieve data for content id 1163
Cannot render a macro when there is no current PublishedContentRequest.

at Umbraco.Web.UmbracoHelper.RenderMacro(String alias, IDictionary`2 parameters)
   at Umbraco.Web.PropertyEditors.ValueConverters.RteMacroRenderingValueConverter.<>c__DisplayClass7.<RenderRteMacros>b__1(String macroAlias, Dictionary`2 macroAttributes)
   at Umbraco.Core.Macros.MacroTagParser.ParseMacros(String text, Action`1 textFoundCallback, Action`2 macroFoundCallback)
   at Umbraco.Web.PropertyEditors.ValueConverters.RteMacroRenderingValueConverter.RenderRteMacros(String source, Boolean preview)
   at Umbraco.Web.PropertyEditors.ValueConverters.RteMacroRenderingValueConverter.ConvertDataToSource(PublishedPropertyType propertyType, Object source, Boolean preview)
   at Umbraco.Web.PublishedCache.XmlPublishedCache.XmlPublishedProperty.<.ctor>b__0()
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
   at System.Lazy`1.get_Value()
   at Umbraco.Web.PublishedCache.XmlPublishedCache.XmlPublishedProperty.<.ctor>b__1()
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.LazyInitValue()
   at System.Lazy`1.get_Value()
   at Umbraco.Web.PublishedCache.XmlPublishedCache.XmlPublishedProperty.get_Value()
   at Our.Umbraco.Ditto.PublishedContentExtensions.As(IPublishedContent content, Type type, Action`1 convertingType, Action`1 convertedType)
   at Our.Umbraco.Ditto.DittoPublishedContentModelFactory.<>c__DisplayClass4.<.ctor>b__1(IPublishedContent x)
   at Our.Umbraco.Ditto.DittoPublishedContentModelFactory.<>c__DisplayClass7.<CreateModel>b__6()
   at Umbraco.Core.Cache.HttpRequestCacheProvider.GetCacheItem(String cacheKey, Func`1 getCacheItem)
   at Our.Umbraco.Ditto.DittoPublishedContentModelFactory.CreateModel(IPublishedContent content)
   at Umbraco.Core.Models.PublishedContent.PublishedContentExtensionsForModels.CreateModel(IPublishedContent content)
   at Umbraco.Web.PublishedCache.XmlPublishedCache.XmlPublishedContent.InitializeStructure()
   at Umbraco.Web.PublishedCache.XmlPublishedCache.XmlPublishedContent..ctor(XmlNode xmlNode, Boolean isPreviewing)
   at Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedContentCache.ConvertToDocument(XmlNode xmlNode, Boolean isPreviewing)
   at Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedContentCache.GetById(UmbracoContext umbracoContext, Boolean preview, Int32 nodeId)
   at Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedContentCache.DetermineRouteById(UmbracoContext umbracoContext, Boolean preview, Int32 contentId)
   at Umbraco.Web.PublishedCache.XmlPublishedCache.PublishedContentCache.GetRouteById(UmbracoContext umbracoContext, Boolean preview, Int32 contentId)
   at Umbraco.Web.Routing.DefaultUrlProvider.GetUrl(UmbracoContext umbracoContext, Int32 id, Uri current, UrlProviderMode mode)
   at Umbraco.Web.Routing.UrlProvider.<>c__DisplayClass3.<GetUrl>b__0(IUrlProvider provider)
   at System.Linq.Enumerable.WhereSelectArrayIterator`2.MoveNext()
   at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at Umbraco.Web.Routing.UrlProvider.GetUrl(Int32 id, Uri current, UrlProviderMode mode)
   at Umbraco.Web.Routing.UrlProvider.GetUrl(Int32 id)
   at Umbraco.Web.Routing.UrlProviderExtensions.GetContentUrls(IContent content)
   at lambda_method(Closure , IContent )
   at AutoMapper.DelegateBasedResolver`2.Resolve(ResolutionResult source)
   at AutoMapper.PropertyMap.<ResolveValue>b__6(ResolutionResult current, IValueResolver resolver)
   at System.Linq.Enumerable.Aggregate[TSource,TAccumulate](IEnumerable`1 source, TAccumulate seed, Func`3 func)
   at AutoMapper.PropertyMap.ResolveValue(ResolutionContext context)
   at AutoMapper.Mappers.TypeMapObjectMapperRegistry.PropertyMapMappingStrategy.MapPropertyValue(ResolutionContext context, IMappingEngineRunner mapper, Object mappedObject, PropertyMap propertyMap)

Any ideas on whats causing the error?

Let me know if you need any more details / logs.

When using UmbracoPropertyAttribute with a property name of a property they physically exists on the doc type model this is currently case sensitive so "name" won't resolve, where as "Name" will. We should make this resolution case insensitive.

We already do that for the DittoPublishedContentModelFactory and it would prevent ambiguity and stop me having to do things like.

using EnumConverter = Our.Umbraco.Ditto.EnumConverter;

For reference, see slide 40 of http://www.zpqrtbnk.net/CoreInternalsForWebsiteDevelopment.pdf#page=40

Implement a custom IPublishedContentModelFactory so that an IPublishedContent can be processed through a custom CreateModel method.

Hey folks,
I'm currently trying out the v0.7.0 release, however when I try populating a POCO from within a POCO it gives an Object not set to reference YSOD when rendering the view. Here's my gist with the code.

On debug, I can see the constructor being called but the Seo object is null. The properties also exist in Umbraco as I've checked they exist.

This code works on v0.6.1 and the properties populate fine.

Thanks,
Jamie