Format function to resolve reference from picker
Closed this issue · 3 comments
When using magic string we can reference a field on page level, e.g. an employee picker: https://docs.umbraco.com/umbraco-forms/developer/magic-strings#umbraco-page-field
However this would just return the Guid, but sometimes it would be nice to reference the email property on that node.
It seems to be possible to add a custom format function, but I wonder it there could be something similar to ncNodeName in Angular?
https://docs.umbraco.com/umbraco-forms/developer/magic-strings#creating-a-custom-format-function
or actually more like mediaItemResolver used in block previews, which resolves the entity and allow referencing properties. Unfortunately we don't have a contentItemResolver which would superseed the ncNodeName, which only resolves the node name, but that is not always what we want.
umbraco/Umbraco-CMS#15291
Adding reference to #1216 where effectively the same issue has been re-raised.
With the next releases we'll have a couple of placeholder formatters that can be used to handle this scenario.
Firstly we've resolved the linked issue #1216 by extracting a serialized representation of the content picker, rather than the name of the published model. We got the latter as we were doing a ToString on whatever comes out of the property value converter, and it was never going to be much use as the information about the data contained in the model is lost. With serialized data we have something we can work with when replacing the magic strings.
Primitive values and strings are handled as they were before, so there will be no change to property's that return those when you get their .Value().
Then we have two new placeholder formatters registered (implementations of IParsedPlaceholderFormatter).
[#pickedContent | contentPropertyName]- will return the content's name for a content picker property[#pickedContent | contentPropertyValue: propertyAlias]- will return the value of the specific property from the content referenced by the content picker
We had some concerns raised with the implementations here in review so have chosen to revert and instead recommend using the "additional data" approach that will be introduced to resolve #578.
As these string values can be provided, and will be available for use as magic strings or in workflows, you would be able to achieve the same result with this. I.e. extract the property you are interested in from the page and provide it as data when rendering the form.