Posted by: Jon Henning
6/9/2006 

In the past blog entry ClientAPI History, Goals, and Controls I stated,

“A few people asked me, the author of the Solution Partners Hierarchical Menu Control, why I would develop a competing menu control to my own.  The answer is simple.  The SolpartMenu is old and carries a lot of baggage with its almost 4 years worth of backwards compatibility.  It has been a goal for v2 of the solpartmenu to abstract all of the common logic not specific to the menu into separate js files that could be reused by other controls and applications.  This is exactly what the ClientAPI is; an abstraction of logic like positioning, DOM access, XML, etc.  The script for the menu should contain only code for the menu, thus making it easier to maintain and enhance.  So in essence, the DNNMenu is in a lot of ways the solpartmenu v2.0.” 

I am pleased to announce that the first non-beta of the DNNMenu will be included in DNN 3.3/4.3.  While its current implementation does not have all the features of the original Solpart Menu, it does include some new functionality that I have always wanted to add.

Keyboard Navigation
The menu can now receives focus as the user tabs through the controls on the page.  Once it has focus, you can use the arrow keys to navigate its structure.  Pressing enter will invoke the menu item's clickaction. 

Populate On Demand
The DNNMenu will support POD in the same manner as the DNNTree control.  This provide a nice performance boost for those of you concerned with page sizes.  I even had time to make the module actions menu support POD.  See chart below for comparisons between each option and other menus.

Mouse In Delay
One of the features of the Solpart menu that was continually asked for was a mouse-in delay.  This delay allows for people who are navigating to the sub-menus and accidentally move off the parent some grace period to get it right.  The DNNMenu defaults this value to a quarter of a second (.25).  I believe this is acceptable, however, for users used to the fast response times of other menus, it may look like the DNNMenu is a little sluggish.  Note:  At this time there is no way of configuring this property in the skin.

No Hardcoded Markup
Probably the biggest regret I had in the original design of the Solpart menu was the hardcoding of certain tags in the code.  This included the NOWRAP attribute added to the menu items, the use of spacer.gif and   to obtain the correct spacing, and the worst of all, the hardcoding of the border around the menu items when hovering.  None of this hardcoding is present in the DNNMenu.  Note:  the one exception is the spacer.gif that is used to do the iframe trick.  I need a url to point the IFrame to in order to not get the security error when the site uses SSL.

In one way or another you will have access to a skin that mimics the existing DNNBlue skin with the release of 3.3/4.3.  There is some talk about switching the default DNNBlue skin with a new one, but nothing is finalized.  Here is a checklist of things to note about writing skin objects for the DNNMenu.

Things to note (skin.xml)

Ø      The nav skin object is used and only supports the organized properties (i.e. CSSNode, CSSControl, etc.) – See the DotNetNuke Navigation Controls.doc document for details

Ø      ProviderName must be set to determine which control to use

Ø      Different css classnames have been chosen for the menu to avoid conflicting settings in default.css, portals.css.  This is mainly due to the workaround necessary for the Solpart borders.  Note, that this does not prevent users from adding these classes to the default.css and portals.css to override things as necessary, just that we won’t default it for them.  I believe this is a good thing, since it should lead to less support issues relating to non-skin specific css.  We have only kept these settings in the past so we wouldn’t break backwards compatibility. 

Ø      By uncommenting the following settings in skin.xml your menu will support Populate On Demand

<!--  Enables Populate On Demand 
      <Setting>
        <Name>PopulateNodesFromClient</Name>
        <Value>True</Value>
      </Setting>
      <Setting>
        <Name>ExpandDepth</Name>
        <Value>1</Value>
      </Setting>
-->

Things to note (skin.css)

Ø      By default the menu uses tables to render all vertical menus.  Any menu that is horizontal will not use tables.  This means that if you use a horizontal menu, the root menu items only are tableless.  All sub-menus use tables (they are vertical).

Ø      Vertical menu items get their css assigned on the TR level.  Therefore it may still be necessary to qualify your menu css with the td.

o       .main_dnnmenu_item td { /*TD if menu option for using tables is on*/

Ø      Word wrapping is now configured on or off via css

o       white-space: nowrap;  /*Word wrapping menu item now optional*/

Ø      The spacing between menu items is no longer hardcoded to be a minimum space.  Therefore it is necessary to add padding to some items to get a decent look.  This is especially true of root menu items that are using a background image for their arrows that indicate children.  If adequate padding is not added, the arrow will render on top of the text.

o       padding: 0px 12px 0px 5px;   /*explicitly set padding for root menu items*/

Things to note (other)

Ø      Uplevel MacIE rendering will not be supported… at least for now.

Ø      Populate On Demand on the module action level may cause issues with a module that dynamically adds their module actions in code.  If you are using such a module it is recommended to simply use a container that does not have POD enabled.  Please note, it is not the module developer's fault for writing their code this way.

Page Sizes and Populate On Demand
In case you are wondering what the total page's payload is depending on the different menus used along with the different options to turn on POD, here is a list of the page trace “Render Size Bytes (including children)” values.  The page used for all samples is the default DNN install page when logged in as host.  The skin is the default DNN-Blue skin where the different ProviderNames are being applied.  Please note, that this is simply to show the different output sizes for the exact same settings.  In order to make each menu look good, some tweaks to the skin will be needed, potentially changing these numbers.

Trackback Print

Tags:

Categories:

Location: Blogs Jon Henning Core :: WebControls