Tuesday, January 27, 2015

What’s a value anyways, and how should it be formatted?

There’s been this interesting discussion on twitter this week about formatting of date values in a the slider refinement template. It started with a post over at http://sharepointroot.com/2015/01/22/sharepoint-refiner-with-datetime-field/ where the issue is that if you use for example LastModifiedTime as your managed property the template will pretty print your years with “one year ago” instead of showing for example 2014. For custom managed properties it will show 2014 – no pretty print for you.

If you add OWSDATE as a suffix to your property name or follow Elio Struyf’s fix from http://www.eliostruyf.com/fixing-slider-bar-graph-refiner-custom-date-time-managed-properties/ then it format properly.

And I want to say that I do agree that it is nice to have values pretty printed. But the discussion has been focused on if it’s a bug or not, with everyone thinking it’s a bug except me (and maybe Elio which hasn’t really taken sides hehe).

Why it’s not a bug

Firstly the oob display templates and refinement templates were made to work for what’s shipped out of the box. If it happens to work for other cases, then good for us. This is at least my point of view. If you want a different behavior you create a custom display template and render stuff the way you want (like Elio explains how to do in his post).

The issue with refiners and data types + parsing is that refiners are returned as ranges in strings. Here’s two samples for the last modified property and the size.

image

image

If you look at the token for each refiner it’s an FQL statement, and the value type won’t be verified until it actually it’s the search query pipeline to verify with the type of the managed property. So between the search engine and the UI, values are text.

If the refinement data coming back had an additional property to say which type it was, that would be grand, but it’s not there. And also remember that passing a refinement back in the query API is just passing some arbitrary additional query parameters. It doesn’t have to be a range on on managed property, it could equally be the name of your dog or an XRANK statement as I’ve written about before.

Also, for a number refiner, how many decimals should be displayed by default, and what if I do want year numbers for dates? Well… I create a custom template.

Conclusion – the way I see it

The way SP choses to format custom managed properties is something you as a developer have to deal with. The OOBtemplates are just that. OOB templates meant to work for SP data and as inspiration for you to work with and extend.

Sometimes they work like we want, sometimes they don’t and we resort to using all og Elio’s excellent tips on how to write awesome display templates.

1 comment:


  1. Ah, Twitter conversations. Aren't they grand?

    My beef with it is that custom date/time properties are rendered on a scale with the years looking like "2,014" or "2,015". In other words the date/time property is treated as a number, not a date/time. It's not about "pretty printing", it's about incorrectly formatting the data type.

    SharePoint knows the data type of the property and should render it as it does any other date/time property. *Then* if we want to make it look different we can create our own Display Template.

    Instead, SharePoint will only treat properties with the suffix OWSDATE as a date/time in refiners. Instead of using the data type, it relies on an overloaded property name. That's just bad coding.

    M.

    ReplyDelete