One of the things I look for when choosing a conference to attend is how much am I going to learn. Past experience has shown me that I learn the most useful information when attending a conference dealing with new technology, which is probably why I choose to attend the PDC conferences. This year, I have the privilege of speaking at a conference about DotNetNuke, specifically about
utilizing controls to build advanced modules. I have spent quite a bit of time trying to determine how to best use my time in preparation of this event. Since my preference in choosing a conference is biased towards new technology, I figured now that the roles are reversed, I would include some new functionality I have been developing for the next version of both the ClientAPI (codenamed Caspian) and the DotNetNuke WebControls (codenamed Dawn Treader). If you haven't guessed, these names were inspired by the Narnia books I am reading to my son. If you never heard of Narnia, think of Jack Sparrow and the Black Pearl.
The following is a brief summary of what will be added in the Caspian release
Convert entire framework to utilize the Microsoft AJAX Extensions
This will require the extensions to be installed, there will be no optional install as the core currently has.
Added new animation library (dnn.motion.js) to support many popular "Tweens" What is a Tween?
One of the things lacking in all of my menu implementations was a set of animations that worked cross-browser. Instead of re-inventing the wheel, I decided to utilize the excellent easing equations available from Robert Penner in a BSD license. While I could spend a lot of time on this topic, Mr. Penner already does a nice job explaining it in his free sample chapter.
ControlMethods
Client callbacks have been around since DNN 3.2. They provide a decent way to have client-side code interact with server side methods. The problem with them is they are not as simple to use as something like PageMethods where you simply create a method, decorate it with a special attribute, invoke it with client-side script, and automagically your method with multiple arguments and complex objects get translated. The problem with PageMethods, however, is that they can only be defined on a page not a usercontrol, and worse yet, they have to be declared static/shared. Therefore, when it comes to developing modules in DotNetNuke, you can either choose to do all your serialization manually and use a callback or you write an external webservice (asmx) and limit the scope of what can be accomplished from a client call (no context of the module).
This is where the ClientAPI's ControlMethods functionality comes in. Simply decorate your control with an attribute on the class,
decorate each method you wish to expose to the client, then use a single method call from the client to invoke the method and let
the framework figure out the details of how to hook everything up.
Utilizing JSON to pass variables
Since the first release of the ClientAPI the ability to pass variables from the client to the server and vice-versa has been possible. This was accomplished by adding a hidden field to the page and delimiting the values within by some rarely used ascii characters. This however, was found to cause issues with validation of peoples pages, and therefore has been replaced to use JSON serialization instead. The only shortcoming of this approach is that the hidden field encodeds all quotes with (") which makes the payload a little larger than I would like. I plan on working on a way around this when I have time.
Embedded and Compressed scripts
All scripts for the ClientAPI will now be embedded into the webutility dll. This allows for easy distribution of the project. However, there is a downside to this approach, as it makes the ASP.NET process work a little harder. Therefore, there will be a new option added to the ClientAPICaps.config file (UseExternalScripts) that allows for a set of external scripts to be used instead. Additionally, in the same manner as the AJAX control toolkit creates a compressed version of the scripts when compiled in release, the ClientAPI will also utilize the JavaScriptCommentStripper.
The following is what is currently slated for the Dawn Treader release
Convert WebControls to .NET 2.0
The conversion of the controls to .NET 2.0 is well over due in my opinion. The next version of the controls will rely on .NET 2.0. Additionally, the sample website for the controls has been completely refactored to include things like master pages.
Convert all controls to utilize the Microsoft AJAX Extensions
This will require the extensions to be installed, there will be no optional install as the core currently has.
Remove use of expandos to pass properties
I have already discussed this item in a past blog. Basically, the manner in which properties are passed to the client will be changed to remove the use of expando properties. Instead these properties will be passed in a separate JSON string which the controls will read in during initialization. The use of expando properties was the primary reason a lot of the DNN controls did not validate.
Remove dnn.xml references from hierarchical controls
This has also been discussed in a past blog. Basically, JSON is better than XML when it comes to handling hierarchical data in javascript. Perhaps someone should consider renaming AJAX to AJAJ.
BehaviorIDs
One nice feature that the control toolkit has is the ability to reference the extender object on the client-side by a simple id using the $find method. By simply specifying a BehaviorID on your extender, you can gain this access. In previous versions of the webcontrol you could access these objects through the dnn.controls.control[YourClientID] collection. Version 2 now introduces the BehavioriD
which will allow access to these objects through the dnn.controls.find(BehaviorID). It is of course still up to you to guarantee the uniqueness of this ID.
DNNTree CheckBoxMode
Probably the most asked for feature for the DNNTree control is the ability to have only a single item checked, or have the parent item control the defaults of its children. Version 2 of the DNNTree has added CheckBoxMode property. The following 3 modes are supported MultiSelect (default), MultiSelectChildren, and SingleSelect. SingleSelect only allows one item to be selected. MultiSelectChildren will automatically select/deselect child nodes recursively when parent is selected
Remove proprietary mozilla Css from Toolbar
The DNNToolbar has been completely configurable via css from the start. Unfortunately, the initial release required the use of a proprietary mozilla css setting.
display:-moz-inline-box;
display: inline-block;
Thanks in part to Timo B. this requirement can now be removed, though a small tweak to the css will be necessary.
DNNMenu RenderMode
A new property called RenderMode will be introduced on the DNNMenu. It will support Normal (existing behavior), UnorderdList, DownLevel, and NoTables (UseTables property is marked as obsolete). When the menu detect a crawler it will now render with an unordered list. More info can be found in this blog.
More control over menu css
The next version of the menu is not only going to include a new rendering mode (UnorderedLists). but also allow for more control over how css can be applied to individual items. The original idea for this was ironed out in this blog, Since then, it has been refined a little more. Instead of defining selectors by an ID, each menu item will be accessible through a css classname. (ex. mi1-2-1, mi2-4-1). Additionally, the first and last items in each menu will have a special class defined (first/last). Finally, each menu will get a class (m1-2). For example, lets say you have a menu similar to the following
File
New
Project
Solution
Open
Exit
Edit
Copy
Paste
This menu will have a menubarclass called .mymenubar. So, all classes we define should limit their scope by .mymenubar. If we were to apply a style to only the Open menu item, the class would be
.mymenubar .mi0-1
The following is how the menu item classes will be assigned
File (mi0 first)
New (mi0-0 first)
Project (mi0-0-0 first)
Solution (mi0-0-1 last)
Open (mi0-1)
Exit (mi0-2 last)
Edit (mi1 last)
Copy (mi1-0 first)
Paste (mi1-1 last)
Similarly you could access the menu's themselves by the m# classes. If you wanted to set the Copy and Paste background to red you would add
.mymenubar .m0-1
If you wanted to change the root (.m0)
Finally, if you wanted to only apply a style to the last item in the File's child menu
.mymenubar .mi0-0 .last
This should be useful for people writing tabbed menus or making your menu bars have rounded corners. An additional note is that these assignments will take place only on the client, so there is no need to worry about increased payload size.
A Note on Compatibility
I have made a large investement in trying to not break compatibility with the contols, and I believe have done a decent job. When planning this release, I was very tempted to convert all controls to use the Control Toolkit, however, this would have broken all compatibiltiy as the controls would have to use a new base class. As it stands right now the only compatibility broken that I know of is the change in the client-side event handler for the TabStrip click event. The reason for this is it required the use of expando properties to work well, and we have chosen to remove this. At a future date, I will be needing some help from the community to verify compatibility with any previous code that was written. If you already know you will be wanting and needing to test for this send me an email.
Hopefully these enhancements wet enough peoples appetites to want to attend my session in this years OpenForce conference.
I don't promise to cover all these enhancements, but I will definitely get to some.