Thread: ComponentArt Menu alternative

I was wondering if anyone has any success with a different menu system.
ComponentArt's menu puts all the JavaScript on the page itself instead of generating a JS file (with a new name every time it is updated so browser's will no longer point to the old version). With 5500 categories, this is hogging up nearly 40% of the page, is never cached by client browsers.
Does anyone know of a menu system that keeps the menu items in a separate file? Or, at the very least, loads the menu portion last so SEO spiders can get the info they need?

TIA!

Originally Posted by mc9000

I was wondering if anyone has any success with a different menu system.
ComponentArt's menu puts all the JavaScript on the page itself instead of generating a JS file (with a new name every time it is updated so browser's will no longer point to the old version). With 5500 categories, this is hogging up nearly 40% of the page, is never cached by client browsers.
Does anyone know of a menu system that keeps the menu items in a separate file? Or, at the very least, loads the menu portion last so SEO spiders can get the info they need?

TIA!

Anyone? This is a deal breaker for upgrading to ML9 for sure!

There are a lot of alternative options to using the component art menu. How would I approach it? I would create a separate XML package for the menu, that would output the categories in the HTML structure I need. Then, depending on the layout I want (dropdown functionality & styles) I might tie in some JavaScript. Otherwise, CSS would be handling most of the styling and overall layout.

I would not load 5500 categories into my menu bar. I could not picture that as being user friendly. This is where using a separate XML package would come in handy.

I've scoured the Internet looking for another menu control that is: tableless (using the unordered lists and CSS) that also can read from an XML file (instead of storing all the data in the client page - which makes the pages absurdly large).
I created a menu about 6 years ago that was pure javascript based. A menu####.js file was created from the admin page whenever new cats were added/deleted. The .js file was numbered so user's browsers would not use a cached version. It did require javascript to be turned on, but was incredibly fast loading (no product at the time compared) and there was no need for complicated cacheing mechanisms, though it was not crawlable by any means (why I don't want to go there). ComponentArt's does not scroll correctly either - some menu items go off the bottom of the page and are un-reachable (the other reason I'd like to switch). Looks like the only solution is to create one from scratch (was trying to avoid).

To be clear, I wouldn't store it in an xml file - I would dynamically create the menu on the fly, by embedding an xml package into my template.