Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at

  • Peter Duncanson 429 posts 1356 karma points c-trib
    Jun 19, 2018 @ 16:40
    Peter Duncanson

    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.


  • Ravi Motha 278 posts 487 karma points MVP 3x c-trib
    Jun 19, 2018 @ 16:49
    Ravi Motha

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

  • Shannon Deminick 1494 posts 5053 karma points hq
    Jun 20, 2018 @ 05:53
    Shannon Deminick

    Some questions to ponder:

    • Where is this extra data going to be stored?
      • Since this is entirely dynamic the easiest way would be to store all of it as a json blob in an NText column on the cmsPropertyType table.
      • Will it ever need to be stored somewhere else like in an external data repository (i.e. not in the default Umbraco db tables)?
    • How is this data accessed?
      • Does it just live as some sort of key/value object on the Umbraco.Core.Models.PropertyType object?
      • Do the values need to be strongly typed?
      • Do these values ever need to be queried? (hopefully not)
      • Does this data need to be accessed via the content cache? (i.e. front-end rendering)

    This would not be able to make it into v7 ;)

  • Andrew Hawken 57 posts 114 karma points c-trib
    Jun 20, 2018 @ 08:56
    Andrew Hawken

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

Please Sign in or register to post replies

Write your reply to: