It has been possible to embed a list of pages into a GNTML document for some time using the |pages:name| block syntax. The meta-data that is used to render this list of pages is automatically syndicated out from the pages which are being included in the list, for example:
Conventional Pages List
This list has pulled in the titles and page descriptions from the related pages and rebuilds the list when it is viewed. So if you update the meta-data about a page, or move a page within the site hierarchy then the list will automatically rebuild itself.
This is all well and good and you can use it to make browsable lists of pages that look like a navigation menu, but the don't have any navigational functionality - ie they don't tell you which page you are on, or which page is a parent of the current page - navigation should be both an indicator of where you could go, but also where you currently are and how you got there.
To this end, I have made a new Presentation style for the plugin which looks at the context of where the list of pages is being rendered and adds the same meta-data to the markup that the m_menu structure that is used to build the rest of the site uses. Here is the same list as before using the Title Menu presentation style:
Menu Functionality Pages List
As you can see, we have 3 different types of pages and they are rendered differently:
Now this example is embedded onto a single page and therefore it is hard to see how the presentation would change depending on where you view it from. However, if you embed the same block onto a cascading document that might appear on multiple pages then the presentation and functionality will change from location to location and the behaviour of the menu is identical to that of the existing template-driven menus that are in use across our sites.
What this means is that we no longer have to extend InForm to model classes of pages that would appear in alternative menu structures - you can just mark them up directly inside the CMS, and you can also utilise any page type in any menu structure which is considerably more flexible than the previous model which involved creating custom versions of <content> pages that would form the menu.
If people want to utilise this functionality then it is probably sensible to talk to your designer about how the different menus should be themed as this will help to reinforce the concept of the hierarchical structure that you are exposing. Theming can either be done on a per-document-type approach (headers, footers, side bars etc) or we can make dedicated template types that implement particular themes and these would automatically be included in the Presentation style widget for each list.