I've been pondering this one for a long while and thought I'd put it out there for some discussion.
I'd like there to be a way to add settings to a property type other than the ones that ship with that property type. So for instance I'd like to add a new field for GraphQL alias or "allow this property to be public on an API" boolean. These are nothing to do with a Multi-Node Tree picker but they are imported meta data that something else I'm working on would find really handy. Now, what I need them for is not the issue, I've had about 3 other packages were being able to add additional meta data around a property type would have been super useful so this discussion is how might we enable that and would anyone else find it useful?
The way I think it might work is you could have a class that would inherit from some as yet non-existent interface (IPropertyTypeDecorator or similar) which would add additional settings to any property type. It would need default values too of course so nothing breaks.
Then when you create or edit a property type these new settings would be there for you to edit and could be used to drive new functionality and packages.
Could it be over-used an pollute the UI...yes of course it could. Could it be super useful for some packages and features...damn right! By adding in this way of working we remove the need to have to keep waiting for a new field to be added in Core (which if honest is probably not going to happen), this instead gives us the ability to add whatever custom meta data we want around a property.
I'm guessing this is a V8 feature but if it could be done in V7 I'd be all ears for that.
I've had a similar requirement - almost exactly the same use case - pick properties to be exposed on an external API (in my case published to CosmosDB). For us the basic requirement was to pick them on an instance basis rather than at the property type level (the Width of a cooker is key information users use as filtering criteria, the Width of a blender is not)
I did wonder if there was a general mechanism for storing meta data against properties or document types. I was imagining some sort of key-value store API rather than a raw ntext field - that way different packages can share it without overwriting their data.
(I solved it with a peta-poco table and a right click on document type to bring out a selection panel with tickbox per property. For my case this is accessed internally in publish events to decide what to serialise.)
Could "Property Type Decorators" become a thing?
I've been pondering this one for a long while and thought I'd put it out there for some discussion.
I'd like there to be a way to add settings to a property type other than the ones that ship with that property type. So for instance I'd like to add a new field for GraphQL alias or "allow this property to be public on an API" boolean. These are nothing to do with a Multi-Node Tree picker but they are imported meta data that something else I'm working on would find really handy. Now, what I need them for is not the issue, I've had about 3 other packages were being able to add additional meta data around a property type would have been super useful so this discussion is how might we enable that and would anyone else find it useful?
The way I think it might work is you could have a class that would inherit from some as yet non-existent interface (IPropertyTypeDecorator or similar) which would add additional settings to any property type. It would need default values too of course so nothing breaks.
Then when you create or edit a property type these new settings would be there for you to edit and could be used to drive new functionality and packages.
Could it be over-used an pollute the UI...yes of course it could. Could it be super useful for some packages and features...damn right! By adding in this way of working we remove the need to have to keep waiting for a new field to be added in Core (which if honest is probably not going to happen), this instead gives us the ability to add whatever custom meta data we want around a property.
I'm guessing this is a V8 feature but if it could be done in V7 I'd be all ears for that.
Thoughts?
I can see this being super powerful in the right hands. its more a case of showing good usage..
Good documentation and samples would be the key...
Some questions to ponder:
cmsPropertyTypetable.Umbraco.Core.Models.PropertyTypeobject?This would not be able to make it into v7 ;)
I've had a similar requirement - almost exactly the same use case - pick properties to be exposed on an external API (in my case published to CosmosDB). For us the basic requirement was to pick them on an instance basis rather than at the property type level (the Width of a cooker is key information users use as filtering criteria, the Width of a blender is not)
I did wonder if there was a general mechanism for storing meta data against properties or document types. I was imagining some sort of key-value store API rather than a raw ntext field - that way different packages can share it without overwriting their data.
(I solved it with a peta-poco table and a right click on document type to bring out a selection panel with tickbox per property. For my case this is accessed internally in publish events to decide what to serialise.)
is working on a reply...