Jon Henning

Introducing DNNMultiStateBox

Mon, 12 May 2008 06:00:00 GMT

One of the new features coming in Cambrian is an update in the permissions grid. The current grid supports two states, Allow and Null (not assigned). The new grid will support three states (Allow, Deny, and Null). The obvious question here is how do you present this to the user? The current design allows for a nice compact way to set the permissions within a grid utilizing checkboxes. The new way will use a new DotNetNuke WebControl that supports multiple states and mimics a checkbox. The original name I came up with for the control was DNNTriStateCheckbox. However, while developing this control I soon realized there was no reason I needed to only support 3 states and saw the opportunity to support any number of states and not necessarily look like a checkbox. So the control is now called DNNMultiStateBox. It is probably the simplest of all the controls in the MVP Summit, I decided to spend a little time optimizing the new ClientAPI (codenamed Caspian) for the Cambrian release. One of the new features for this release was to allow the output of the ClientAPI and Webcontrols to emit compliant markup (more detail mentioned in this blog). There was two areas that this affected my code.

Javascript Global Namespaces (the dreaded $ function)

jon.henning@dotnetnuke.com — Mon, 24 Mar 2008 08:00:00 GMT

The whole idea of the $ function and who "owns" that "namespace" has become quite muddy. When I first learned of the use of $ and found that MS was adopting the same notation, I decided to do it as well. For at the time, I felt that all frameworks simply used it as a quick way to get the reference to a DOM element. Soon afterwards I learned that frameworks like prototyle use it for much more.

Searching for the "Holy Grail" of Menu Item Customization

Wed, 14 Nov 2007 17:43:03 GMT

For a long time now many skinners for DotNetNuke have felt like customizing individual menu items was like looking for the Holy Grail. All the menus I have contributed to the community (Solpart and DNNMenu) have always had the ability to customize each menu item. The problem always was
how do we allow DotNetNuke the ability to customize the items? The only place the unique menu structure is known is after the portal is created, well out of reach of someone providing a generic skin to fit any site. Sure there are those portal admins out there that know enough about css to make it work, but there still was a problem in how to access each item directly in css.

I have been considering options for how to overcome this for some time now, and am currently working on the 2.0 version of the webcontrols which should contain one possible solution. However, those controls are far from complete so I decided to offer a minor hack along the same lines.

First, let us consider eclayf's idea from the forums, where I borrowed the name of this blog entry from. The idea is to loop through all menu items and assign a background image to each item based off of the icon assigned. This allows the background image to be customized by the portal admin.

To try this idea out add the following code to your ascx page using the DNNMenu (not solpart). I tested with default blue for DNN.

This should cause the icon images to be displayed as the background.

Note: I noticed that if your skin declares the background-color (as the default blue does), the hover will no longer display the background. If you change it to not set the background then the image remains.

While this works, it is far from ideal. For one thing the admin menu item icons are not customizeable. Probably the biggest shortcoming is you can only customize the image, which happens to meet eclayf's requirements, but not generic enough to implement for DotNetNuke.

The idea I have been toying with is allowing the next version of the menu to support known client-side IDs. My current thought is to allow the skin to decide whether to go this route by providing a "safe" known namespace. For example, in your skin you would have a property like ClientIDPrefix="jcompany", then on the client each node will be assigned a unique id, prefixed with that text. So the root would be jcompany__0, jcompany__1, etc. The child of
jcompany__2 would be jcompany__2_1, jcompany__2_2, etc. This way it would allow the skinner
to predefine as many levels as he/she sees fit, and as long as the user of the portal doesn't exceed the predefined number, the skin should work as originally intended. Even if the skinner doesn't provide the level necesssary (something like jcompany__2_2_1_3_5), there is nothing stopping the user from adding the css himself, perhaps copying the value from a class defined higher up. The only pitfal in this approach is the worry about overlapping prefixes with other controls on the page.

In order to try this concept out add the following code to you ascx file that uses the DNNMenu

Then in your css file add something like

#jcompany__0
{
	background: red;
}

#jcompany__1
{
	background: blue;
}

#jcompany__1_0 td
{
	background: green;
}

#jcompany__1_1 td
{
	background: orange;
}

Note: It is worth noting that in general it is a bad idea to change the ids of a any control, as it most likely will break the control when it does a lookup by its id. In the DNNMenu's case, those references to the lookup are cached internally, thus this reassignment of ids will work.

Right now this is just an idea I'm toying with. If people like the approach I probably will include it in version 2.0 of the DNNMenu. Any feedback on this would be welcome.

BETA TEST PROGRAM: ClientAPI/WebControls - DawnTreader and Caspian

Thu, 18 Oct 2007 22:10:23 GMT

The conversion of the ClientAPI and WebControls to utilize the MS AJAX Framework along with emitting xhtml compliant markup is near completion. It is now time to start testing the backwards compatibility of the conversion. In order to adequately do this, I am asking for the communities help. If you are a skinner who uses any of the DotNetNuke webcontrols (DNNMenu, DNNTreeView, etc.) your assistance is needed. If you are a module developer who uses any portion of the ClientAPI or any of the WebControls, you assistance is also needed.

Interested in ensuring that your investment in DotNetNuke is backwards compatible? Follow the instructions in this thread.