Display SelectMany-items in PropertyList:s with SelectItem:s Text

Display SelectMany-items in PropertyList:s with SelectItem:s Text-part when multiple items selected

Jonas Carlbaum

Vote:

When having a PropertyList with Selection Factories, like this.

[PropertyDefinitionTypePlugIn]
public class FooBarSettingsPropertyList : PropertyList<FooBarSettings>
{
}

public class FooBarSettings
{
    [SelectOne(SelectionFactoryType = typeof(FooSelectionFactory))]
    public virtual string FooSelection { get; set; }

    [SelectMany(SelectionFactoryType = typeof(BarSelectionFactory))]
    public virtual string BarSelection { get; set; }
}

We have an ok presentation of FooSelection and BarSelection when selecting only one item, the Text part of SelectItem is presented.

However, when we select many Bar:s, so that there is the ID (a string in GUID-format) comma-separated stored in DB, we are seeing the comma-separated string of GUID:s, not the comma-separated presentation of Text-parts of the SelectionFactory.

Expected output would be something like Kaka, Baka, Smaka, Foo, Bar or something.

I don't think we should be expected to implement Dojo/Dijit stuff to fix this, maybe it should work using string[] or List<string>, or some extra UIHint, or it should simply just work out-of-the-box.

#222855

Edited, May 12, 2020 11:44

Jonas Carlbaum

Vote:

...I mean, it's not that complex like PropertyList inside PropertyList or ContentArea inside PropertyList, it's something that is actually mapping Value to Text of SelectItem in correct ISelectionFactory already — when only one item (not comma-separated) — so it seems like it could be solved with a comma-split in these cases, somewhere in default grid presentation!?

#222858

Edited, May 12, 2020 12:37

Jonas Carlbaum

Vote:

...so without knowing the implementation I'm thinking that you maybe could iterate the comma-splitted DB-value items and compare them with Value in the ISelectionFactory and extract Text instead of compare and map ISelectionFactory with the exact DB-value...

Of course it could be more complex to fix than I thought...

#222863

May 12, 2020 14:38

Mark Stott

Vote:

PropertyLists have quite a few limitations, even now, standard properties such as ContentReferences and Url fields do not render in a user friendly manner. It's a shame as I rather like the functionality if you don't want personalization of the data and want a consistent object type.

You're going to have to look at your own solution for this. I use PropertyLists a lot in one particular build which can contain images, content links and urls, I used the following blogs as a guide and built up on them to make them more robust and to reduce the attribute overhead. You should be able to take what is written in these blogs to fulfil your own specific requirements:

#222909

May 13, 2020 16:35

Jonas Carlbaum - May 13, 2020 18:29

Yep!
I know that, but we like to avoid Dojo/Dijit if possible. Since we see this as a matter of quality of the CMS product and built-in features we see it as EPiServers responsibility to improve this. These things as you and I mention should have a `prettyPrint`-presentation in grid, a sensible default. And dojo/dijit is on the roadmap to be replaced — in a not known future, so we are more keen in letting EPiServer solve it, improving the product and maintain functionality during these future transitions...

Mark Stott - May 14, 2020 8:07

I think EPiServer has changed tactic on child data by focusing on the Block Enhancements. But it would be nice if they were to make Property Lists feel like a completed feature.