I have a pretty deep main navigation menu, much of it drilling down into user data. I am convinced that fully populating the menu is impacting site performance. I am looking for a solution that doesn't compromise drilldown functionality.
Here are a couple of ideas I had...
I have scoured the documentation for an example of how to do either of these things... no luck yet.
Either method would require creating submenus using javascript, and I have not located documentation of how to do that either. It is not addressed in the CSOM documentation or any of the published samples that I could find.
Does anyone know of a good resource I can look at to get me started with either solution?
Hello,
WebDataMenu is not designed to support lazy loading, nor load on demand.
It is specific navigation control, which, in most cases represents a navigation scheme of a site. Being part of navigation scheme, it is supposed (and in most cases correctly) that each item point to a different page. Having load on demand will cause client side delays on each and every page where the menu is placed, which might cause bad user experience.
For load on demand and lazy loading you can opt for WebDataTree, whic is optimized for deep and big data structure navigation.
I think you're mistaken that such capabilities aren't warranted for a navigation control. Please allow me to illustrate.
There are valid site navigation patterns where a submenu presents several optional pages related to the parent menu item, and the submenu is virtually duplicated for each instance of every parent menu item. Forcing the creation of these submenus to the server ignores significant performance benefits that can be gained by allowing these submenus to be created on the client.
This is a valid site navigation pattern...
For the sake of discussion, please have a look at the following screenshot:
In this example, every single "route" node has an "Edit" and a "Print" submenu item. Every one of those submenu items must be created on the server, transmitted to the client, and loaded into the client.
If there are 50 Route nodes, then there are 100 Print and Edit nodes, increasing the size of the HTML (and the work required to build the menu) by 300%. If we want to provide any additional options to a route, each option doubles the size of the menu!
Because of their repetitive nature, the Print/Edit submenus might ordinarily be implemented as a context-menu, but our users aren't sophisticated enough to figure out right-clicks, etc. And it just makes sense for them to fly out from their parent menu item.
Implementing this as a tree, since it is a navigation function, would be awkward at best.
If a javascript function could be implemented to build the print/edit submenu on mouse-over of the route nodes, it would:
Even if that part of the menu building couldn't take place on-hover, but instead was done in a lazy fashion after the page loads, it would still yield the same benefits.
Even with the legacy WebMenu, there were requests from people to be able to create menu items through javascript, and it was seen as a significant product shortcoming that no such capability exists. I find it hard to believe that there are no plans to implement such capabilities into the WebDataMenu.
I am a *very loyal* Infragistics customer... but if there are seriously no plans to introduce client-side menu construction, then I seriously need to consider looking outside Infragistics for a menu control.