Copied to clipboard

Flag this post as spam?

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


  • Hendy Racher 807 posts 3602 karma points admin core
    Apr 06, 2017 @ 10:40
    Hendy Racher
    0

    Context & Property Value Converters

    Hi,

    Is it possible within a Property Value Converter to obtain the context id of the IPublishedContent on which the property is on ?

    For example:

    var obj = umbracoHelper.TypedContent(123).GetPropertyValue<MyModel>("propertyAlias");
    

    In the Property Value Converter:

    public override object ConvertSourceToObject(PublishedPropertyType publishedPropertyType, object source, bool preview)
    {
      // how to get the context id of 123 ?
    }
    

    Thanks, Hendy

  • Dave Woestenborghs 2341 posts 6545 karma points mvp c-trib
    Apr 06, 2017 @ 10:48
    Dave Woestenborghs
    0

    Hi Hendy,

    Don't think it's possible. Maybe you can shed a light on what you are trying to achieve ?

    Dave

  • Hendy Racher 807 posts 3602 karma points admin core
    Apr 06, 2017 @ 10:58
    Hendy Racher
    0

    Thanks Dave, I feared that may be the answer; when we create a nuPicker.Picker object it needs to be aware of it's context - this is so that if values are progmatically changed and it's using Relation Mapping, it can update the relations appropriately, and if the picker is using "Relations Only" then there isn't a saved value hence it needs to know the context so it can query the relations data.

    I don't suppose you can think of a work around ?

  • Hendy Racher 807 posts 3602 karma points admin core
    Apr 06, 2017 @ 11:05
    Hendy Racher
    0

    I should add that when querying the current content it works fine as we can get at that via:

    UmbracoContext.Current.PublishedContentRequest.InitialPublishedContent.Id 
    

    but this is an assumption being incorrectly made in the nuPickers PropertyValueConverter.

    A fix might be to ensure the saved value contains all the necessary data, but this would be breaking as we'd like to support formats such as CSV without adding extra meta data.

  • Dave Woestenborghs 2341 posts 6545 karma points mvp c-trib
    Apr 06, 2017 @ 11:38
    Dave Woestenborghs
    0

    I see the issue you are having..the content item you are doing the conversion for is not always the "current page".

    But sadly, I don't see a solution. Just looked at Umbraco source and don't see something that would make it possible.

    Dave

  • Hendy Racher 807 posts 3602 karma points admin core
    Apr 06, 2017 @ 11:41
    Hendy Racher
    0

    I suspect this data could be useful for other PropertyValueConverters too, I wonder if there's a suitable way to implement a PR for this ?

    Update: issue U4-8306

  • Stephen 707 posts 1982 karma points core hq
    Apr 07, 2017 @ 17:04
    Stephen
    1

    At the moment there is no way a property value converter can refer to the "owning" content item. That being said, I'm interested in understanding the use case and see whether it's something we should add.

    I don't know the nuPicker "relation mapping" very well but from what I understand, item A could pick other items via relations, and if eg item A is modified to pick item B, then item B should automatically reflect that it picks item A - is that correct?

    Which would mean that the converted value for item B needs to change, even though item B itself hasn't changed. Would that describe the situation? Otherwise, could you give me more details?

    More infos: the result of a property value conversion can be cached at different level. Conversions that only depend on the content itself (eg, converting a CSV string to a List) can be cached for as long as the content is not modified. Conversions that depend on the content tree (eg, converting an integer ID into another content item) can be cached for as long as the content tree is not modified. Conversions that depend on anything else should be cached at request level (so, one conversion per request). IIC what you would like to do is have your own custom cache level/implementation - and that would require that the converter knows about the "owning" content identifier. Is that it?

  • Hendy Racher 807 posts 3602 karma points admin core
    Apr 08, 2017 @ 12:40
    Hendy Racher
    0

    Hi, yes, you've described exactly how the 'Relations Only' feature should work in nuPickers - the pickers don't store any local value, so need to lookup their value based on their context.

    In terms of caching (for nuPickers anyway) the existing Content (as pickers could pick Media / Members or any other Umbraco item) and Request level (for Relations Only) should be OK as there is internal caching of relations when in Relation Only mode.

    I guess the first question should be, would any other PropertyValueConverters benefit from knowing their context ?

  • Lars-Erik Aabech 312 posts 1008 karma points mvp c-trib
    Apr 21, 2017 @ 15:32
    Lars-Erik Aabech
    1

    @Stephen, one of the reasons why I'd like to access the owning item from a property value converter is that we often "fall back" to another configurable property. It should just be exposed as that fallback value in the property instead of the view having to specify the alternative. We've got a couple where we fall back to one property, if it's empty, we fall back to another, and finally we fall back to content.Name. It's used for instance for "SEO Title", which falls back to "List Title", then "Heading", then "Name". Today we do the fallback in the angular controller for the property editor, so it's evaluated, then saved as { "value": "", "fallback": "value of other property"}. Converter returns fallback value if value is empty. It would be better to do this in the converter, and it would work well with caching.

    I've had other cases where I'd wanted it, but can't remember them ATM. I'll post again if I stumble upon them. :)

Please Sign in or register to post replies

Write your reply to:

Draft