The use of @currentField
allows you to request specific values when the field is an object (Person and Lookup). This works great if you need the person's name since you can just use @currentField.title
.
However, other fields don't return as objects they return as separate values with a . in the name. For example, a Hyperlink field comes back as FieldName and FieldName.desc both as top level properties (not as an object).
It is expected that you would be able to pass @currentField
with a Hyperlink field to get the URL and then pass @currentField.desc
to get the display value.
The _evalJsonPath
method splits the @currentField
value on the period then evaluates the results from the row object using only the first portion. This makes it impossible to retrieve properties that contain the . as is the case with Hyperlink fields.
So no combination of @currentField
or [$FieldName]
will work since the . is always stripped out before the evaluation is done. So although the FieldName.desc value exists it is comletely inaccessible and an error will always return.
Apply custom formatting to a Hyperlink column and set the txtContent
to @currentField.desc
Instead of immediately splitting the value in the _evalJsonPath
method then evaluating the parts, a check against the row for the existence of the property as passed should be done. Something like:
this._params.row["someLink.desc"]
If this evaluates, then that's the value that should be used and you can skip the splitting and object evaluation that current exists (and works for User and Lookup fields).
Alternatively, a check could be made for the field type (as is done with Number, User, and Lookup) and if it is a Hyperlink then the evaluation could be simplified.
Hello, thanks your your analysis and feedback. We're looking at this currently. Are there field types other than Hyperlink and Picture that you'd like to be able to retrieve more properties for? Or is it just those two?
|Field/Type|Additional Value|Note|
|----|----|----|
|Hyperlink|fieldname.desc|Link display text|
|Created Date|Created_x0020_Date.ifnew|converted to bool|
|Currency|fieldname|formatted value|
|Currency|fieldname.|float value|
|Boolean|fieldname|formatted value|
|Boolean|fieldname.value|bool value|
|DateTime|fieldname.FriendlyDisplay||
|File Type|HTML_x0020_File_x0020_Type.File_x0020_Type.mapico|file type icon|
|File Type|File_x0020_Type.progid||
|File Type|File_x0020_Type.url||
|Item URL|.spItemUrl||
|File Type|.fileType|this one can also just be accessed using File_x0020_Type|
Currently Number fields just get the float value (fieldname.
) assigned to them directly. This isn't a problem. Similarly, Boolean fields end up just getting the bool value (fieldname.value
) assigned to them. This isn't a big deal, but it would be nice to be able to get the Yes/No formatted values (for display) as well as the direct boolean value (for operations) - currently can only get the boolean value.
I'd also say that the DateTime FriendlyDisplay value is not really necessary (at least for me), but I wouldn't think it would be too hard to support it as well.
Document libraries also return several properties starting with a period that may or may not be helpful (the only one I would likely use is the .fileType
shown in the table above): .hasThumbnail
,.hasVideoManifest
,.hasPdf
,.hasOfficePreview
,.hasBxf
,.ctag
Noted that this is still an issue with Hyperlinks, but wanted to add that updates to this need to ensure that @currentField continues to return the Url value to avoid breaking custom formats already in use.
Most helpful comment
|Field/Type|Additional Value|Note|
|----|----|----|
|Hyperlink|fieldname.desc|Link display text|
|Created Date|Created_x0020_Date.ifnew|converted to bool|
|Currency|fieldname|formatted value|
|Currency|fieldname.|float value|
|Boolean|fieldname|formatted value|
|Boolean|fieldname.value|bool value|
|DateTime|fieldname.FriendlyDisplay||
|File Type|HTML_x0020_File_x0020_Type.File_x0020_Type.mapico|file type icon|
|File Type|File_x0020_Type.progid||
|File Type|File_x0020_Type.url||
|Item URL|.spItemUrl||
|File Type|.fileType|this one can also just be accessed using File_x0020_Type|
Currently Number fields just get the float value (
fieldname.
) assigned to them directly. This isn't a problem. Similarly, Boolean fields end up just getting the bool value (fieldname.value
) assigned to them. This isn't a big deal, but it would be nice to be able to get the Yes/No formatted values (for display) as well as the direct boolean value (for operations) - currently can only get the boolean value.I'd also say that the DateTime FriendlyDisplay value is not really necessary (at least for me), but I wouldn't think it would be too hard to support it as well.
Document libraries also return several properties starting with a period that may or may not be helpful (the only one I would likely use is the
.fileType
shown in the table above):.hasThumbnail
,.hasVideoManifest
,.hasPdf
,.hasOfficePreview
,.hasBxf
,.ctag