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 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.
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.
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
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 ?
@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. :)
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:
In the Property Value Converter:
Thanks, Hendy
Hi Hendy,
Don't think it's possible. Maybe you can shed a light on what you are trying to achieve ?
Dave
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 ?
I should add that when querying the current content it works fine as we can get at that via:
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.
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
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
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
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 ?
@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. :)
is working on a reply...