AllowedTypesToAdd includes derived classes

[deanebarker]

When creating a ContentManagerViewConfiguration, the AllowTypesToAdd will cause Content Manager to display that type, and all types that derive from it.

For example, consider this code in a default Alloy implementation:

public class PageView : ContentManagerViewConfigurationBase
{
    public PageView(UIDescriptorRegistry uiDescriptorRegistry) : base(uiDescriptorRegistry)
    {
        Id = "pages";
        ViewTitle = "Page Manager";
        Root = new ContentReference(5);
        AllowedTypesToAdd = new[] { typeof(StandardPage) };
        SortOrder = 3;
    }
}

That view will display all content of type StandardPage and all content of type ArticlePage, because that extends from StandardPage.

This should not descend into the class structure. If someone also wants ArticlePage they should need to add it to the array.

[barteksekula]

AllowedTypesToAdd follows the default EPiServer's AllowedTypes which works the same way. https://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Content/Properties/Property-types/Restricting-content-types-in-properties/

[deanebarker]

I don't think the usage pattern maps exactly from that to Content Manager. Perhaps we should have a boolean for AllowDerivedTypes?

In a larger sense, what if someone wants to list content based on something other than type? I wonder if there's a way to make the entire thing pluggable. Perhaps with a delegate?

public Func<IContentManagerViewConfiguration, IEnumerable<IContent>> ItemFactory;

You could write a function to do whatever you wanted:

ItemFactory = (vc) => {

    var resultOfVoodoo = new List<IContent>();
    // Do some strange voodoo here
    return resultOfVoodoo;

};

The default implementation would be provided. It would just filter on types like it does now.

[barteksekula]

Fixed in https://nuget.episerver.com/package/?id=EPiServer.Labs.ContentManager&v=0.2.1

[deanebarker]

Can you explain the fix? How does it work now?