home / bulletins / 13 / page 4

[previous]

New, Easier to Manage Configuration File Format

Versions 4 and 5 of HierMenus used a JavaScript based arrays format to specify menu configurations and parameters. While this format was compact, it offered very little in terms of maintainability to site authors. The primary drawback of an array based menu configuration is remembering which "slot" a particular parameter setting was intended to occupy; and then ensuring that all the slots leading up to that position had valid entries, even if each slot was to be empty. Additionally, many users found our menu naming structure, which was based on the names of the arrays themselves (i.e., HM_Array1_2_3 for the menu that appears when the third menu item, of the child menu that appears when the second menu item of the parent menu is rolled over, is rolled over) cryptic and difficult to maintain. Adding a new menu item in an upper level menu, for example, virtually required that all the child menus (and all of their grandchild menus, and so on) be renamed to match the new structure.

In HM6, the configuration file setup is changed from an array based style to a functional, object based style. The key difference? With an object based style, parameters can be identified by names as opposed to array number "slots." For example, creating a blank menu in the new configuration file may look as simple as this:

HM_f_SetMenus({
   MenuID:"MainMenu",
   IsHorizontal:true,
   IsPermanent:true
});

Similar functions are provided for the setting of menu items, global defaults, and new "Menu Templates" that are automatically applied to all menus created after the template is defined. Now, it's much easier for someone with the thankless task of maintaining this menu to see that the above statement creates a horizontal, permanent menu. Further, notice the use of the plain text MainMenu for the name of the menu. It is this name that will be referred to in other menu definitions, meaning that you can add new menu items to MainMenu without breaking your relationships between child menus (which, for example, might have names like ProductsMenu, ServiceMenu, or even FooBar.) Since you decide what your menus are named, and you link child menus to items by this name (and not some name that depends on the order or position of the menus themselves), you can design menu naming structures that are easier to understand and maintain in the future. Menu names must be unique, must begin with a letter, and may contain letters, numbers, hyphens, and underscores. Even with these restrictions, you will still enjoy a tremendous amount of flexibility in your name selection.

For those of you upgrading from version 4/5 array structures, a conversion tool will be provided allowing you to quickly convert your existing arrays to their new object-based counterparts.

Custom Code in the Loader

Some of the features described above are implemented via the inclusion of custom code in the HM_Loader.js file. While this isn't possible or practical in all cases, where it makes sense we will continue to follow this "custom code in the loader" rule, so that if you decide you don't want to utilize a particular feature, you can simply remove that code from the loader file, lightening the overall download impact for your site visitors.

A prime example of custom loader code (that you may or may not want to utilize), is that relating to our old nemesis, the showing of select boxes through HM menus in Internet Explorer 5-6. We recently introduced code (during the version 5 release cycle) that allowed you to hide all the select boxes on a page when an HM menu is displayed. This code, called HM_f_ToggleElementList, is now included in the loader file for quick access (or quick deletion, if you don't need it). In addition to the HM_f_ToggleElementList code, the loader file now includes custom code that can be used to implement an IFRAME based masking technique that allows HM Menus to cover select boxes (and other windowed elements such as Flash applets as well) in Internet Explorer 5.5 and 6 only. This technique has been "making the rounds" on the bulletin boards over the past year, and is based on a unique capability of IE IFRAMES that is documented in Microsoft's knowledge base here:

MSDN - IFRAMES and Windowed Element zIndex settings

Again, this particular technique, while very effective, will work only in IE5.5 and 6, meaning that some users will not want to bother with it. Since the code that implements the technique is located in the HM_Loader.js file, it can be easily deleted if not wanted.

Menu "Event" Hooks for Developers

Especially for developers, HM6 will feature HierMenus "event" hooks that you can grab to let you know about a particular event that's happening within the HierMenus code. Such hooks may allow you to make minor modifications to a menu's parameters on the fly, or perform some action external to HierMenus in synchronization with a HierMenus action. Much of the custom code snippets described above utilize these hooks to implement some specific action against the internal HM Menu objects themselves at critical points of the HM process.

The "full slate" of event hooks and implementations that we intend to support is not yet finalized; but you can count (at least) on hooks signaling the toggling of a menu's visibility, the movement of a menu, and the creation (pre and post) of a particular menu.

Conclusion

As is always the case, we greatly appreciate all of the support and suggestions we receive from our HierMenus users and fans. Keep an eye on this site for the arrival of HierMenus version 6; which we hope to be landing very soon!

[previous]