...I mean, it's not that complex like
PropertyList, it's something that is actually mapping
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!?
...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...
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:
When having a
PropertyListwith Selection Factories, like this.
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, Baror something.
I don't think we should be expected to implement Dojo/Dijit stuff to fix this, maybe it should work using
List<string>, or some extra
UIHint, or it should simply just work out-of-the-box.