So, the client side application I’ve been working on has to sync a LOT of terms to the term store, and I’ve mentioned how I had problems with Managed Metadata labels and the ampersand – and how I fixed them using TaxonomyItem.NormalizeName().
Well, that was fine, but my application was slow – so I started looking at what I could do to eliminate client side object model calls (CSOM). My suspicion was that, as the function was static, it wasn’t doing anything that I couldn’t do in my application, and save a round trip to the server.
So, I opened up reflected and decompiled Microsoft.SharePoint.Taxonomy.dll. Inside I found the code for the following:
Regex _trimSpacesRegex = new Regex(@"s+", RegexOptions.Compiled | RegexOptions.IgnoreCase);
//Normalize name as Taxonomy Service does
string name = _trimSpacesRegex.Replace(termName, " ").Replace('&amp;', 'uff06').Replace('"', 'uff02').Trim();
That’s much, much faster than a round trip to the server, and I learnt that speechmarks are also converted from ASCII to Unicode too.
I am writing an application to import/generate a number of terms in a term set. I started to get some errors about my code trying to add terms that already exist – but it does check for the existence of terms with a given name.
You can see that the string comparison for the name of the existing term and the term I want to get/create returns false, and that the terms seem to be different lengths. Well, I tried looking for blank spaces, non-printing characters, carriage returns, etc., and found nothing. Then I looked really closely at the ampersand characters shown in the debugger:
Yup, they’re different characters. You can see a slightly different shape to each of them – one is wider. Continue reading “Managed Metadata Labels and the Ampersand character”
SharePoint’s Taxonomy (or “Managed Metadata”) fields are a bit strange in how they work. In a lot of ways they’re actually like a lookup field, and part of this lookup field is that site collections that use them have a hidden list – called TaxonomyHiddenList – in the root of the site collection. You can find it at /lists/TaxonomyHiddenList/.
Each term that is used in a Taxonomy field has it’s label (actually, labels) and other details kind of ‘cached’ in this list, and there is a timer job that will push changes to the terms out into these lists – and therefore to items that refer to the entries in the list. Continue reading “What happens with a large TaxonomyHiddenList?”
I’ve come across a few issues lately with list column indices (indexes?) in SharePoint that have caused some trouble recently.
- Multi-valued columns cannot be indexed. It doesn’t matter what type they are, they can’t be indexed. This isn’t actually so surprising when you think about it – where in the index would they be – though it might be nice if they simply appeared in it twice. To be honest, I’d known this for some time, but it did catch me out recently.
- Lookup Columns can’t be used in ListViews set up through the UI. It seems that the SharePoint UI sets the list view up to filter using the ‘text’ of the column, which isn’t indexed – rather than using the LookupId, which is. A List View in a list definition, or set up through code, can therefore be fine…
- The Approval Status column added by Content Approval can’t be indexed.
- Single-valued Managed Metadata (Taxonomy) columns can be indexed – but not sorted. ORDER BY clauses won’t work (more on how to solve that in a later post). I think this is due to multi-lingual support – but it is a pain.
Yes, some of these issues are particularly acute given some of Office 365’s search limitations, and awkwardness with Content Approval.
SharePoint search can crawl managed metadata fields, and it stores the values inside a Text search property. But what are the values stored there? What format are they in? Do they contain the path to the term/s, etc?
Well, the project I’m working on needed me to retrieve some managed metadata fields from the REST search API. Continue reading “Get the text out of a Managed Metadata Search Property”
So, I’ve somehow managed to get through most of the SP2010 cycle without having to use the Enterprise Content Type hub – until last week. This was my opportunity to stumble across one of the gotchas of the ECT hub – it doesn’t work with blank sites. We had a number of site collections based on the Blank site template, and content types would not replicated to it. Other site collections based on other templates – such as Team sites – worked fine.
Interesting. And this tickled a neuron. Continue reading “Content Type Hubs and the Blank Site Template – Fixing them”