You can add a property for each template e.g. "umbracoNaviHide" as boolean (true/false)

If this is checked (true) for a page, exclude this page from navigation

in xslt, you can use something like below:

<
 
xsl:for-each select="$currentPage/ancestor-or-self::node [@level=1]/node [string(data [@alias='umbracoNaviHide']) != '1']">
...
</
 
xsl:for-each>

Otherwise, create a document type e.g. menuItem with only one property e.g pageLink (page picker). Create navigation structure using this document type which allows you adding any level of pages. You can create menu from this root scanning through all children nodes.

naviHide isn't going to work as the structure doesn't match.

single property doc-type seems like the way to go, but seems messy too

Another option is create a custom data type which accepts any number of entries, and each entry has a 'Page Link' and 'Parent Page Link'. Based on this data, you can create navigation but its more complex!

Hi Chris,

I'd go for a solution as the one below (may need some tweaking)

<!-- subNodes could be list of sub nodes, have to set condition for those 
     could be umbraco.library:GetXmlAll()//node [@level = 2] or umbraco.library:GetXmlAll()//node [@nodeTypeAlias = 'alias']
     List should now contain A1, A2, B1, B2, B3, C1, C2
-->
<xsl:variable name="subNodes" select="umbraco.library:GetXmlAll()//node [CONDITION]"/>
<!-- Iterate nodes at highest level A, B, C, probably $level = 1 (Need to add another variable for this)-->
<xsl:for-each select="$currentPage/ancestor-or-self::node[@level = $level]">
  <xsl:variable name="currentNode" select="."/>
  <!-- Get list of matching nodes from subNodes (those subnodes A1 thorugh C2 for which you've set the content picker to refer to node A, B or C-->
  <xsl:variable name="matchingNodes" select="$subNodes/node [./data [@alias = 'PROPERTYALIAS'] = $currentNode/@id]"/>
  <ul>
    <li>
      <!-- Output node A, B, C -->
      <xsl:value-of select="@nodeName"/>
    </li>
    <ul>
      <!-- Ouput maching nodes (eg for node A, you'll get sub node B1 -->
      <xsl:for-each select="matchingNodes/node">
        <li>
          <xsl:value-of select="@nodeName"/>
        </li>
      </xsl:for-each>
    </ul>
  </ul>
</xsl:for-each>

Basically, you add another property on sub node doc type and set datatype to content picker. For each of those sub nodes, choose the top level node to which it should belong in the navigation.

Cheers,

/Dirk

i have approached such a challenge with a CONFIG HOME node, that contains various CONFIG nodes under it... i have a config node called topNav -- it has a related nodes dataType on it...

then you can use this the navigation....

your xslt will just render the nodes that are contained on that config node... there is an xslt template for relatedItems to even get you started.

Hope this helps

I used to work with a CMS that separated content structure from Navigation. It sounded like a good idea at the time, but was ultimately just wasted effort for the editor.

What's the reasoning for your content structure to not match you navigation?

You'll have a difficult time highlighting the heirachical navigational parent elements.

Are you sure the structure can't be adapted? What is the reason?

I think the problem lies there, not at the menu hacking. Fix the structure fix the problem.

You could always make have the ugly solition for having one content picker for each top menu and one related links for it's submenu. Dirty dirty solution, but it's easy if you need changes, and wouldn't be that much trouble to 'highlight' the current page in the menu.

I like Paul's solution best out of everything that has been suggested so far.  Simple but not that obvious to someone looking for an overly technical solution.

To all who commented on the structure issues - yes I agree it seems funny, however the top menu is trying to provide an overview of key site functionality which has roughly 7/8 different directions to go.  The site is structured in a way that suits breadcrumbs, however, the top menu doesn't match that.  In short - I'm happy that the site structure is correct, and that the logic for building the menu as I want to is sound.

Thanks again for all the solutions offered - they did open up possibilities I hadn't considered.

Cheers, 

Chris

My solution for quickmenu is like this using small xslt and add a property type related links. Very easy olso for editors to configure.

<ul class="menu-quick-links">

<xsl:for-each select="$currentPage/data [@alias = 'QuickMenu']/links/link">

<li>
<xsl:if test="position() != 4">
<xsl:attribute name="class">grey-quicklink</xsl:attribute>
</xsl:if>

<xsl:if test="position() = 4">
<xsl:attribute name="class">red-quicklink</xsl:attribute>
</xsl:if>

 
 <xsl:if test="./@type = 'internal'">

<a href="{./@link}">
    <xsl:attribute name="href"><xsl:value-of select="umbraco.library:NiceUrl(./@link)"/></xsl:attribute>
<xsl:value-of select="./@title"/>
</a>

</xsl:if>
</li>

</xsl:for-each>
</ul>

is working on a reply...