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.
Seeking an update from Infragistics on this issue. I have not been able to find anything in 10.3 that seems to address this.
That is wonderful news!
I would *love* to volunteer to participate in the beta, if such an opportunity exists.
However, if 10.3 doesn't include this function, I'll have to move to a different vendor for our menu until y'all have a solution.
Cheers,
-Rob
Hey,
We have plan to support client side databinding, which will tremendeously decrease page load time, traffic and size of HTML, since no HTML will be initially loaded for the menu - just data. And with the support for client side databinding binding will also come support for Data Service binding.
In response to your comment:
It would pay to have a look at what your competition is doing...
http://demos.telerik.com/aspnet-ajax/menu/examples/programming/webservice/defaultcs.aspx
Here is a menu that not only supports adding and removing menu items on the client... but also supports binding to a web service.
The client delay for the ajax call is nearly indiscernable... and it is more than justified by the quicker page load time *on each and every page* due to the initial load state of the menu being much smaller.
Come on guys... don't make me resort to the competition. I just need to know that you have a plan to address it, and I'll stick with ya to see it through.