Hi Mark! We have a lot of block types with IList<T> properties where T is a POCO type.
We're not using IList<T> where T is a block type in this case, so I don't think we're mixing the two (let me know if I misunderstood what you meant).
This exact setup works if the Link property is, for example, of type ContentReference.
So I think this should work, but there seems to be a bug related to serialization?
Or is Optimizely officially removing the support for POCO types, forcing all IList item types (except value types) to in fact be block types going forward?
Not answering the question directly, but maybe you can be interested in Geta Generic Links - they try to solve need similar to what you/ve described https://www.getadigital.com/no/blogg/extending-link-item-collections
There can be some issues with Content Management API though (thats how I stumbled on that package) so be warned.
I'm trying to add a
LinkItem
property to aPropertyList
type (I can't use LinkItemCollection as I need more properties on each item), but this fails during block creation and results in a stack overflow (stack trace can be found further below).I've set up a basic example in a new Alloy project on the latest CMS version (12.22.4), and the block type looks like this:
And the item type looks like this:
I've also set up a basic property definition for this (empty class inheriting
PropertyList<ExampleListItem>
).This setup fails instantly once you create a new block in a content area and select the ExampleBlock type.
I've also tried decorating the LinkItem property with
[JsonConverter(typeof(SystemTextLinkItemConverter))]
(using the System.Text.Json.Serialization namespace for the attribute), as I believeUrl
properties require the same approach in PropertyLists, but this does not help in this case.Is there anything I'm missing here, or a possible workaround to get this to work?
Part of the stack trace (last few rows keep piling up):