<nSiteMaps:SiteMaps.Primary>
<nSiteMaps:NodesCollection>
<nSiteMaps:CommandNode Title="Refresh" IconPath="/Images/expand.png" CommandBinding="{Binding RefreshCommand}" />
<nSiteMaps:CommandNode Title="Search" IconPath="/Images/menuenabled.png" CommandBinding="{Binding SearchCommand}"/>
</nSiteMaps:NodesCollection>
</nSiteMaps:SiteMaps.Primary>
<nSiteMaps:SiteMaps.Secondary>
<nSiteMaps:NodesCollection>
<nSiteMaps:CommandNode Title="Settings" CommandBinding="{Binding MessageCommand}" CommandParameter="Show Settings" />
<nSiteMaps:CommandNode Title="About" CommandBinding="{Binding MessageCommand}" CommandParameter="Show About" />
</nSiteMaps:NodesCollection>
</nSiteMaps:SiteMaps.Secondary>
<i:Interaction.Behaviors>
<nBehaviors:BridgeViewModelBehavior/>
<nBehaviors:BridgeApplicationBarBehavior/>
</i:Interaction.Behaviors>
So basically above, you declare two sets of "SiteMaps" - a primary and a secondary one. Then the BridgeApplicationBar Behavior turns the Primary SiteMap to the AppBar's Buttons and Secondary SiteMap to the AppBar's MenuItems. Also the nodes can be NavigationNodes or ControllerActionNodes or even your own custom node types - so it's quite flexible.
Now, if you wanted, you can also source the entire nodes from elsewhere, like from the App.xaml declaration or your VM. Consider:
</phone:PhoneApplicationPage>
Now, as of now this is not fully finished, but does anyone have an opinion on if this is good, bad, or ugly?
Also FYI, the Primary and Secondary SiteMaps will also be available in both WPF and SL, the idea being (as Garth wanted) that you can expose a set of functionality in a standardized way that can be integrated in the shell or be used to source a menu. Further, like with SiteMaps this functionality could come from a db or be created in real-time etc.