Welcome Guest Search | Active Topics | Sign In | Register

eo:Menu Max Menu Depth (and/or slow load time) Options
AndyKowal
Posted: Tuesday, January 15, 2008 11:46:29 AM
Rank: Newbie
Groups: Member

Joined: 1/15/2008
Posts: 8
I am binding the eo:Menu to an asp:SiteMapDataSource. The web.sitemap file has approx. 400 items and some submenu items are 5 levels deep, but most are only 2 or 3 levels deep. When the page loads the eo:Menu is very slow to respond to mouse hovers until the page finishes loading.

To isolate the menu I created a very simple page with ONLY the eo:Menu bound to my SiteMapDataSource. Trace information shows a total of only 0.0559808579023312 execution time, but it takes about 4 seconds before the menu responds well to mouse hovers. During those 4 seconds the menu is very sluggish.

I set DebugLevel_Off in global.asax:

Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)
' Code that runs on application startup
EO.Web.Runtime.DebugLevel = EO.Web.Consts.DebugLevel_Off
End Sub

...and I set EnableViewState="False" for my page and the eo:Menu.

Two questions:
1. Is the sluggish start-up due to the size and depth of my web.sitemap?

2. Is there a way to limit the submenu depth in eo:Menu regardless of the menu depth in web.sitemap? (Other menu controls I tried have a property like .MaxDepth...)

One last note -- we are evaluating eo:Menu and are ready to purchase a license if this issue can be resolved. I must say that once the menu is fully initialized this is THE best and fastest menu control we have tried. Our only concern is the initialization time.
eo_support
Posted: Tuesday, January 15, 2008 12:13:02 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
Hi,

The sluggish is due to total number of menu items. The server code executes rather fast, but the client side code that initializes the menu items is slow (Especially apparent in IE. It runs much faster in FireFox). When the page loads, the menu initializes the top level items first, so that you will immediately see a menu, it then initializes all the sub level items on the background. And that takes a lot of time. The issue has nothing to do with ViewState or menu depth.

Unfortunately the ultimate solution to this problem is to reduce the total number of menu items. Another way is to replace the menu with a populate on demand TreeView (a non populate on demand TreeView will have the same problem because of the number of nodes), that way the total number of items/nodes created when the page loads can be reduced.

Thanks
AndyKowal
Posted: Tuesday, January 15, 2008 12:20:42 PM
Rank: Newbie
Groups: Member

Joined: 1/15/2008
Posts: 8
Thank you. Understood RE populate on demand Treeview, I'll try that next. And like you said, it DOES run very fast in Firefox.

* In the meantime, is there a way to limit the menu depth for a particular instance of eo:Menu?

I understand that the depth is not the problem, but limiting the depth would significantly lower the total number of menu items in our case, so it should eliminate the sluggishness. The reason I can't just delete lower submenus is we need the complete site map for other components in the site.

Thanks!
eo_support
Posted: Tuesday, January 15, 2008 12:44:47 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
Hi,

There isn't a MaxDepth setting on the menu. But it's fairly easy to populate the menu first, then trim the deep items off. And yes, once you trim down the total number of items, the menu would speed up. The following code would do so:

Code: C#
protected void Page_Load(object sender, EventArgs e)
{
    Menu1.DataBind();
    TrimMenu(Menu1.Items, 2);
}

private void TrimMenu(EO.Web.MenuItemCollection items, int maxDepth)
{
    foreach (EO.Web.MenuItem item in items)
    {
        if (maxDepth <= 1)
            item.SubMenu.Items.Clear();
        else
            TrimMenu(item.SubMenu.Items, maxDepth - 1);
    }
}


Note DataBind must be called before you can trim the menu. Otherwise the items are not there yet.

Thanks
eo_support
Posted: Tuesday, January 15, 2008 12:46:36 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,217
One more note. Make sure you keep EnableViewState as false. Otherwise the "trimming actions" themselves will be logged in the view state and get accumulated over postbacks.
AndyKowal
Posted: Tuesday, January 15, 2008 1:21:25 PM
Rank: Newbie
Groups: Member

Joined: 1/15/2008
Posts: 8
Perfect. Exactly what I needed. Now we can strike a balance between number of items and performance.

Thanks!


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.