U4-10005 - Add property in package.manifest to re-use property value converters for simple types

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.

However as a frontend developer this might be an extra step and the cool thing about property editors in Umbraco v7 is that you can do a lot just with html, css and javascript without knowing about C#.

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:

  • String
  • Int32
  • Boolean
  • (decimal/double/float) - e.g. for property editors allowing to store decimal values, like Umbraco.Decimal property editor.
  • (DateTime)
  • (String/int array) - e.g. as Umbraco.MultipleTextstring

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

1 Attachments

Comments

Bjarne Fyrstenborg 12 Jun 2017, 11:19:52

@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 :)


Søren Kottal 12 Jun 2017, 11:42:58

This would be awesome!

Maybe even add StringArray, Int32Array etc.

Or IPublishedContent, IPublishedContentArray (taking a Udi or csv of Udis and convert to IPublishedContents)


Bjarne Fyrstenborg 09 Oct 2017, 13:29:03

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.


Lars-Erik Aabech 09 Oct 2017, 13:47:03

If none of the simple types, how about allowing a fully qualified type name and automagically do JsonConvert.DeserializeObject() on it? :)


Søren Kottal 09 Oct 2017, 13:53:07

@lars-erik that would be totally awesome.


Bjarne Fyrstenborg 09 Oct 2017, 14:17:17

@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.


Bjarne Fyrstenborg 23 Nov 2017, 22:09:29

@Shandem @zpqrtbnk do you have any thoughts about this? :)


Ronald Barendse 08 Mar 2018, 13:12:03

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?


Priority: Normal

Type: Feature (request)

State: Submitted

Assignee:

Difficulty: Normal

Category:

Backwards Compatible: True

Fix Submitted:

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:

Sprint:

Story Points:

Cycle: