Optimizely finally releases new and improved list properties!

For years, the Generic PropertyList has been widely used, despite the warning at the top of the documentation. It's unsupported functionality. Also, any links and references inside such lists are not tracked by Optimizely, and you will not be warned of incoming links when deleting content.

A warning for the old and obsolete Generic PropertyList

I'll illustrate the difference between the old way, and the new way released today, with an example. I'll create a list of persons, each with a name, image, and one internal link.

The old Generic PropertyList – stay clear!

This is not the recommended way, but was one of the options until today.

Create a class that holds the information for one person.

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

    [UIHint(UIHint.Image)]
    public ContentReference Image { get; set; }
    
    public PageReference FavoritePage { get; set; }
}

Add a property like this to your content type, and reference the Person object.

[EditorDescriptor(EditorDescriptorType = typeof(CollectionEditorDescriptor<Person>))]
public virtual IList<Person> PersonObjectList { get; set; }

Then tell Optimizely CMS that you really, really intend to use this as a property.

[PropertyDefinitionTypePlugIn]
public class PersonListProperty : PropertyList<Person> { }

That's it!

When you add new Person items to your list, it looks OK. The only drawback is the lack of drag-and-drop support for the image and link properties.

A more critical problem is the list view, where you see the content id of the image and linked content, rather than the thumbnail and content name.

If you like to get your hands dirty, you could fix this using Dojo or this addon from Jake Jones. Don't do that, use the new List Properties instead,

The new List Properties – use them!

If we were to create the same list of Persons using the new approach, we would create a block type for holding the Person details. That way all the good stuff like export/import and permanent link handling is taken care of.

[ContentType(AvailableInEditMode = false)]
public class PersonBlock : BlockData
{
    public virtual string Name { get; set; }
    
    [UIHint(UIHint.Image)]
    public virtual ContentReference Image { get; set; }
    
    public virtual PageReference FavoritePage { get; set; }
}

Then add the property to your content page.

public virtual IList<PersonBlock> PersonBlockList { get; set; }

That's it, no need to explicitly define a new property type!

Adding new Persons look a lot like before, except now we've got drag-and-drop support from both the assets pane and the page tree.

In the list view, you've got the same properties and preview that we are used to from regular properties. The thumbnail is shown for the image and the content name for the page.

The blocks can be expanded, collapsed, and edited inline without the need to open a new dialog.

I want more!

This is all good, but I would love to see some improvements!

• When all blocks are collapsed they all look the same. I would like to be able to define a property that is shown instead of the block name («PersonBlock» in the above example) when the block is collapsed. For Persons the Name-property would be an obvious choice.
• Drag-and-drop reorder! Currently, sort-order can be updated by clicking the context menu for a single item, then «Move up» or «Move down». If you have a lot of items, that does not work too well. I want drag-and-drop!

Update

It's now possible to specify the what property to use when the list items are collapsed, so they do not all look the same. This fixes my first suggestion for improvements.

[ListItemHeaderProperty(nameof(Blocks.ContactBlock.Heading))]
public virtual IList<ContactBlock> Contacts { 
  get; 
  set; 
}

Furter reading

While I was busy writing this blog post, Bartosz Sekula published a great write-up covering more of the details. Have a look!