Well, it's finally time to gear up for a new version of HouseMenu. Much has changed with DNN, and I would like to hear from users out there about what's important to them in a navigation solution for DNN.

I will definitely strive to keep HouseMenu as lightweight as possible, and it will be as javascript-free as I can make it. Beyond that, let's talk!

One of the questions I am really wrestling with has to do with architecture: Should HouseMenu be implemented again as a module/skinobject, or should it follow the new navigation provider model? I'd like to go with whatever is easier for the user, and I'm leaning toward the module/skinobject route. Please share your thoughts.

And feel free to comment on any existing or potential feature!

Hi Tim,

I like the skin object route, it's simple to implement and get working in skins. - would the navigation provider model offer any benefits?

Lee, I am experimenting with the provider model approach right now, and I actually have it up and running. I guess the biggest advantage of this approach is that you don't have to make specific skins to work with different menu controls: you just set the default in web.config so all standard skins use the selected menu, or else you open a skin and change a setting in the navigation object's tag.

In the case of HouseMenu, this might not be so big of an advantage. Most of the settings for the core navigation object are ignored for HouseMenu, and the CSS has to be customized anyway.

Still, I am now leaning toward going that route since it is the "prescribed" approach now. Although I could certainly make it available both ways and let people choose their own approach.

Clay,

Thank you for your feedback.

You can do the per-page image thing with the current version of HouseMenu, but it only supports one image. You have to set a page icon in the page settings and then tell HouseMenu to use this image (with or without the page name). This is clearly only part of what you were describing.

It would be straightforward to store selected pages and their various images in a database table, then use this to build a highly customized menu. Homwever, it would add some overhead, and I really want to keep HouseMenu very small. This would also almost require the module/skinobject approach in order to avoid a bit of a torturous installation.

But I kind of like this idea all the same, so I'll keep it in mind.

Hi Tim,
I am running into one thing I would love to see a feature of.  I have some pages that are hidden and when a user clicks on that menu item hat is the parent I turn on the Show all nested and also turn on show hidden. 

Is there any thoughts on making a check that says show nested to current page?  I want to have the complete nested for a particular branch but not for the others I have not expanded on.

here is an example of what it looks like when you are not clicked on it and one when it is expanded.

If you are at the root level of the menu this is the correct menu you should see:
http://beta.nths.org/About.aspx

If you are at the "Types of Membership" page you should see the 3 children:
http://beta.nths.org/About/TypesofMembership.aspx

As you can see it expands all of the as there is no option to just expand the children of the current page.

Thanks
Rick

Rick,

This should be possible. Other users have requested functionality like this before, so I am definitely looking at adding it.

I'd suggest possible thinking about multi-language support.

Perhaps the 'multi-language' aspect of things should be elsewhere like during the page creation process but this would require some sort of core modification which is likely a ways down the road.

Hmmm. Well, if this is a wishlist that's something I would add. Erik (?) at Apollo Software has a menu replacement/modification that allows something like this but it's a modification of solpart I believe.

I wonder if implementing version 2 as a provider model would allow some sort of localization component (eg. one that tracks page names in multiple languages) to tap in and feed to the menu system the appropriate language?

Perhaps someone with more knowledge can kick in.

Definitely a good idea, Brian. I actually corresponded with Erik about adding his multilingual solution to the earlier HouseMenu once upon a time. Should be pretty straightforward to adapt that earlier code to the new version.

Thanks for the suggestion, David. Can you describe what you mean in a little more detail, please?

I think you mean the menu should show siblings of whatever the current page is, whether that's at the top level or two levels down. Right?

Tim

that's right, it should show the siblings of the currently active page.

and maybe you can go one step ahead and also give the possibility to choose from which level the menu should start (in my case the submenu shouldn't display the root level)

cheers, david

Hi Tim,

I have an idea to add as perhaps a future enhancement to all this. In my previous post, I suggested using an additional table to allow the storage of images and item specific styling.

In thinking about this approach more, I am becoming more convinced of the value of adding that additional table for referencing. My thoughts on it are these.

With an additional table you would also be able to make the Skin Object "self aware" in the sense that the table could assign an "instance number" to each implementation of the object in the skin. This would allow you to assign specific root level pages to an instance (or perhaps second level pages from a hidden page or something like that) in this way, a person could create a standard type skin with several "instance" implementations of the skin object "out of the box" which would then make the object "dynamic" in that it could access that table in a "settings" area much like modules do. This would simply be awesome in my view.

We could then have multiple instances of HouseMenu in a skin, each "self aware" as to its own instance,,, something like " instance=1," "instance=2," etc. This would take the place of the dnnMenu and Solpart "starttabid=x" setting.

Does this make any sense to you? I hope it does. Allowing the use of an additional table that would store the "instance" to which root pages could be assigned would create a huge amount of flexibility in implementing the HouseMenu. IMHO.

So, do you think I have totally lost it, or does this all make sense?

Clay

[Edit] 
By the way, it would also solve the sort of quandry posed by Jon Henning in his blog about making skins more flexible and more useable by skinners.

http://www.dotnetnuke.com/Community/Blogs/tabid/825/rssid/8/Default.aspx

Clay,

Thanks for the additional suggestions. I think you might be onto something here, but I'll need to digest this all and give it some thought. Feel free to elaborate as you keep thinking about this, too.

Tim

I would like the next version to be able to Localize the admin and host menu, when using an other locale.
If eg. I use Danish as default language on my portal, I set the default language of the admin/host to danish and login as admin/host - the admin/host menu is still in english. 
it would be nice if this could be possible.

I really want to make HouseMenu easy and flexible, which makes for a constant balancing act.

Here's what I'm thinking for customizing specific items in a menu, which is what I think you are after, Clay....

As HouseMenu renders each menu item, it will include the page name as an id. For example, the rendered markup for a single item might look like this:

<li id='site_page_name'><a>...a>li>

So to style specific menu items in the CSS, you would simply target the specific item within a specific menu:

#menuId li#style_page_name {...}

No need for a database table and full CSS for styling an item. Does this meet your needs for flexibility?

Tim