We have moved to GitHub Issues
Created by Bjarne Fyrstenborg 11 Jun 2017, 12:09:20 Updated by Bjarne Fyrstenborg 08 Mar 2018, 13:58:06
At the moment when you have a custom property editors and are working with either strongly typed models or using ModelsBuilder in Visual Studio, one has to implement a property value converter to return a specific type. It does make sense in many cases e.g. when storing json and one want to convert this to a specific model.
For example in my own package Switcher https://our.umbraco.org/projects/backoffice-extensions/switcher/ I can implement a property value converter to return either false or true (while ModelsBuilder at the moment just return an object). However it might be a bit overkill to add an extra assembly just for simple types and checkbox property editor already has a converter for this to return true/false from a stored int 0/1 - it would be cool if you just could re-use built-in property value converters in Umbraco core for simple types:
I imagine the package.manifest could have a property for return type or output type like in the screenshot. https://our.umbraco.org/documentation/extending/property-editors/package-manifest
@Shandem @zpqrtbnk I have created this feature request after talking about with you guys about this during CodeGarden. It would be cool if this is possible :)
This would be awesome!
Maybe even add StringArray, Int32Array etc.
Or IPublishedContent, IPublishedContentArray (taking a Udi or csv of Udis and convert to IPublishedContents)
Maybe it would be enough to extend "valueType" property with more possible values, e.g. "valueType" : "BOOL" (or "BOOLEAN"), will return the object as boolean, but store the value as int i database as it does with checkbox datatype.
It will then based on this value decide which value type to stored in db and which property converter to use.
Not sure if it could break any existing property editors. Without an property value converter it returns an object and it the example in the screenshot I can add .ToString() on the object and compare against 0 or 1. When return type is int instead of object, it should still work, but changing to bool (and return type would be boolean) existing code using the datatype, would probably need to be modified.
As I remember, when changing valueType in package.manifest, it doesn't update datatype in db for existing instances of the property editor.
If none of the simple types, how about allowing a fully qualified type name and automagically do
JsonConvert.DeserializeObject() on it? :)
@lars-erik that would be totally awesome.
@lars-erik that would be great too, but I think most packages working with json include one or more assemblies. As a start I think it will be great for frontenders, when working with ModelsBuilder, without the need for a property value converter for simple data types.
@Shandem @zpqrtbnk do you have any thoughts about this? :)
Most of this functionality could be created with a single
PropertyValueConverter by implementing
IPropertyValueConverterMeta that looks up the correct return/value type from the manifest, right?
I would be explicit about this, so add a
propertyValueType and even a
propertyCacheLevel (since Object, Source and XPath values are the same - at least for simple types - having a single cache level should be enough).
I recon most work is in updating the property editor code to allow for these extra properties, but maybe someone with more knowledge about this could give some more insight?
Type: Feature (request)
Backwards Compatible: True
Affected versions: 7.6.0, 7.7.0, 7.6.1, 7.5.14, 7.6.2, 7.6.3, 7.6.4, 7.6.5, 7.8.0, 7.6.6, 7.7.1, 7.7.2, 7.7.3, 7.7.4, 7.7.5, 7.7.6, 7.7.7, 7.7.8, 7.9.0, 7.7.9, 7.7.10, 7.7.11, 7.8.1, 7.7.12, 7.7.13, 7.9.1, 7.9.2
Due in version: