次の方法で共有

SharePoint Managed Navigation, Part 2

  • [アーティクル]

Last time we looked at the why Navigation Node Type was a key local property for terms in a term set used for navigation. That enables us to now talk about details of other managed navigation related properties for a term. I want to go into some detail on these properties as appropriate and will preface each set with a screen shot of the relevant section in the term store management tool.

Navigation Tab

 

  • Navigation Node Title
    • Allows the use of an alternate string to be used in navigation menus. If not customized the default label of the language for which the web is based. Managed Navigation does not ever use anything except this property or the default label of the language matching that which the web was originally provisioned in. i.e. different labels for different languages will not be used based on the locale of the web nor based on browser locale detected in combination with alternative supported languages. For this reason there is not a Navigation Node Title per language.
  • Navigation Hover Text
    • The text that will appear when hovering on the navigation menu item for this term.
    • Manifests itself as the value for the anchor tag title attribute.
  • Visibility in Menus
    • Available for either global or current navigation this property dictates whether or not a menu item will appear for this term.
    • This is a very important property to have it allows you to have terms in the term set which do not actually render in the UI for navigation. Consider a scenario where pinning is very important to use instead of plain reuse but one of more terms of the pin source hierarchy should not render a navigation menu item.
  • Navigation Node Type
    • Discussed in Part 1 as a key differentiator for two major experiences with managed navigation and as the driver for changing between two separate but overlapping sets of properties to work with on the Term-Driven Pages tab.
  • Associated Folder
    • Now that a URL may be a FURL and is not necessarily representative of site structure this property is used to hint at when it is appropriate to modify style of a navigation menu item based on the page the user is current on.

 

Term-Driven Pages Tab w/ Navigation Node Type of Simple Link or Header

 

 

As we approach the Term-Driven Pages tab a basic understanding of cross site collection publishing (XSP) goes a very long way. That begins here with the third property. There is an overview that includes Cross Site Publishing here.

  • Friendly URL Segment (for child terms)
    • For child terms of this term that are set to be Term-Driven Navigation Node Type you still would need a segment of the FURL defined to represent the parent in hierarchy.
    • You can customize the segment or leave it to appear as the default label of the term for the language of the web.

  • Target Page Settings (for child terms)

    • As a default for child terms that do not specify their own you can provide here a target for access to their FURLs.

  • Catalog Item Page Settings

    • Regarding Cross-Site Collection Publishing, even with the particular term target navigation node type being simple link and not rewritten to a FURL there can exist FURLs that do not go through any further hierarchy but rather represent access to an individual item tagged with this category and to be viewed through an item page.
    • This property specifies for this term what the catalog item page should be for access to items from the category.
    • The page specified here will be presented for any FURL …/ThisTerm/[anythingExceptChildTerm] where everything that does not directly match the label for a child term of ThisTerm is considered a primary key presumably used as context for the Catalog-Item Page.

 

Term-Driven Pages Tab w/ Navigation Node Type of Term-Driven Pages with Friendly URL

 

  • Friendly URL for this term
    • Much like with the other navigation node type except this obviously now applies to customizing the piece of the FURL at the actual target of this term and not just children.
  • Target Page Settings – Target for this term
    • Used in Part 1, simply the page to be rendered for a FURL leading to this term.
  • Target Page Settings – Target for children of this term
  • Category Image
    • Allows you to choose the image related to this term. Used by the Term Property Web Part.
  • Catalog Item Page Settings – Catalog Item Page for this category
    • Same property as Catalog Item Page Settings for simple link or header node type.
  • Catalog Item Page Setting – Catalog Item Page for children of this category
    • A default for child terms for the page to be pulled for items of the category.
    • Same as Target Page Settings (for child terms) with the other navigation node type.

 

And there you have it. Not all properties are as interpretable at first because they are based on a unique feature set for the reuse of content from different sites in the current site (XSP) with a navigation experience that can be modified easily through the term store or is designed to represent information architecture as opposed to site structure (which or may not have been representative but regardless is now largely permanent). These properties are probably just Catalog-Item target settings.

Navigation related term properties tend to be local and not shared because if tagging sets are used to build portions of multiple navigation terms sets through simple reuse or pinning then these properties being shared would brutally limit flexibility for the navigation of all except one of the webs (the one in which they are correct versus all others who share the values then that may or may be desired different).

Comments

  • Anonymous
    January 30, 2013
    Why oh why doesn't the navigation term automagically retrieve the navigation link label based on the used MUI language? It would be really useful. Now this basically makes it impossible to use the managed navigation with multilingual sites. :(