Last week Beta 2 of 6.0 was released, as many of you already know, and my colleague Joe Brinkman took the time to highlight a few of the lesser known features/enhancements introduced in 6.0 as well of some of the updates we made based on feedback from previous CTP’s and Betas. Since reading his blog, I have been reminded of another feature/enhancement that has been overlooked thus far: Telerik wrappers. Before diving into what exactly was added for developers to take advantage of, it might be good to provide some history related to the controls as well as our usage in the updated user interface for 6.0.
History
In DotNetNuke 5.2, we introduced the inclusion of the Telerik.Web.UI.dll. With the inclusion of this assembly, valid Telerik license holders as well as DotNetNuke PE customers were free to develop third party extensions (ie. their own custom modules) using the Telerik controls. CE edition users were free to use third party or core extension that utilized the Telerik controls but they were not permitted to develop using these controls. In order for CE edition developers (basically, any extension developer who does not have a PE license) to develop using these controls, core wrappers had to be written. In the initial release (5.2), there were very few (if any) wrappers available. As time went on, DotNetNuke added more and more wrappers and also updated Telerik assembly versions but many controls never had a proper wrapper. Basically, this meant that CE developer had very little Telerik control options.
With the introduction of 6.0, this is no longer the case. Yes, the same license rules/restrictions exist but now we have proper wrappers for everything included in the latest Telerik release at the time of this writing. While this may seem like no major benefit, that is far from the truth. These wrapper additions allow any DotNetNuke extension developer (so long as they use the wrappers) to make the most of the Telerik ASP.NET Ajax control suite. For end users, this means rich functionality in more modules because more developers can utilize the controls.
6.0 User Interface
If you followed along with the previous 6.0 CTP’s and Beta, you have seen how the user interface has transformed over the course of the 6.0 development cycle. As Joe mentioned, the initial implementation of the UI relied heavily on Telerik controls. As work on the user interface progressed, we started moving away from Telerik and going more with jQuery & jQuery UI. There were a number of reasons for this but I think the previous link does a pretty good job of outlining some of those.
So now, pretty close to a final release, I think it might be a good time to discuss what Telerik controls are still being used. There may be a few places I am overlooking, but the list below summarizes everywhere I could think of that we are using Telerik in the core distribution.
- RadGrid (DnnGrid) – I assume this will eventually replace all data grids in the core (many already using it as of 6.0). Please note, there are a number of column type wrappers too being used for the grids.
- RadDatePicker (DnnDatePicker) – Replacement for Client API calendar.
- RadComboBox (DnnComboBox) – Language Selector, Control Panel. Should only be used when added functionality is needed (like an image, HTML in drop down list). The DNN Terms selector control uses this too (seen in edit page settings tags section).
- RadAjax (DnnAjaxPanel, DnnAjaxLoadingPanel) – This is what you see when partial rendering is enabled in a module (any module). In 6.0, out of the box, you see this when you click login.
- RadTreeView (DnnTreeView) – I believe every treeview in the core, besides the file manager, is using this (and already was).
- RadEditor – Used in the provided HTML editor provider.
I am pretty sure there are a few random controls used in some of the admin/host modules and/or in the PE/EE modules that I didn’t mention, but the list above should give you a good idea of what to except to see consistently in modules that require the provided functionality for each control across the majority of the core UI.
NOTE: Designers (and developers) may want to take note of the z-index attribute defaults set by the various Telerik controls here. You may also want to view the jQuery UI ones here.
For 6.0 Developers
When it comes to the individual Telerik controls and working with them, each could be a separate blog of its own. However, if you are familiar with Telerik controls (or you follow their examples), using them in DotNetNuke doesn’t require too many changes. Instead of going through each control, I thought it would be best to use a module where I have many Telerik controls already being used so I converted my DNN Rad Tag Cloud module over to 6.0 and utilized all the new wrappers. FYI, this example also makes use of the module branding and modal popup support added in 6.0.
A few general notes on using Telerik wrappers in DotNetNuke:
- Every control included in Telerik's 2011 Q1 SP2 release has a wrapper in 6.0.0.
- For the most part, Telerik controls start with Rad but their DotNetNuke equivalents replace Rad with Dnn (RadGrid = DnnGrid, for example).
- All wrapped controls are in the DotNetNuke.Web project & it’s output dll.
- Telerik enumerators are not wrapped, you will still have to use them as shown in Telerik examples in your cs/vb code (not necessarily something most developers would come across).
- Partial Rendering support probably needs enabled in your module controls. Depending on which Telerik controls you use and how you use them this will vary but this is a good rule of thumb.
- Only use Telerik when it provides some value. There is no reason to replace a standard drop down list that just displays text with the Telerik ComboBox. Telerik controls tend to output lots of HTML that just isn’t necessary for most (I understand why they do it, but it’s not always easy for designers to work with).
- There is no design time support in Visual Studio.
I suspect that if Telerik creates new controls, DotNetNuke will likely follow up with a corresponding wrapper in its following release. Please keep in mind, when Telerik does a new release there is some latency until they provide us a DotNetNuke specific assembly plus the time we need to test it prior to inclusion in a new DotNetNuke version.