As a developer of hundreds of custom DotNetNuke extensions I have to say one of my favorite enhancements to the DotNetNuke platform over the last few years was the inclusion of the new DotNetNuke Form Pattern that was part of the 6.x release. By incorporating a consistent design pattern it became trivial for extension developers to build modules that had similar UI patterns and would thus have consistently styled applications. By doing this it is possible to make the understanding of flow within your applications easier as you are leverage a UI style that more similarly matches that of the platform itself. However, as with any new feature, it hasn't come without a few "bumps" in the road. There were a few changes between 6.x and 7.x that have caused a bit of a problem for those of us that have already adopted the patterns, or those that might. In this post, we will look at these differences and the one small change that you can make for a seamless experience regardless of if you are targeting 6.x or 7.x!
A Look at 6.x
Prior to the release of DotNetNuke version 6.0.0 there were no publicly posted standards for the layout of forms. Sure, we have had the Label control for years. (The little thing with the help icons for those unfamiliar.) However, each module developer would roll their own way of laying out forms. Many people would use tables to handle the layout of inputs and sometimes legacy CSS classes would be used to have some semblance of consistency, however, there was no published "best case".
With the release of 6.0.0 of DotNetNuke, the entire UI had been redesigned, action menus changed, and a new paradigm of interaction was introduced with the addition of out of the box support for Modal dialogs. Sometime after the initial launch of 6.x the DotNetNuke User Experience Guide was released to the public. Using this guide it is possible to see how you can use all of these new design patterns in your modules. For example how you can get the nice little "red bar" style field indicators or the little arrow point error messages.
This guide was fantastic, comprehensive, and up-to-date! Many people, myself included jumped on this design pattern quickly and started using it in all of our projects to speed development and also as a side benefit the div based layout made responsive designs much easier for clients!
Introducing DotNetNuke 7.x
Although the changes in 6.x were fantastic there was still more room for DotNetNuke to improve. One of these keys to this improvement was the further refinement of the UI patterns for DotNetNuke 7.x. If you look at a basic form in DotNetNuke 7.x you will see that it is similar to that of a 6.x form with a nice clean/consistent style but that required fields are now being indicated by a more traditional red asterisk rather than the red bar that wasn't so friendly with all designs.
Small change right? Yes, it was, in fact, a really small change, but how do we deal with it? The UX Guide website has not yet been updated to reflect the changes in DNN 7.x and there has been no real official guidance on what it should be. To the user is it two small changes, the removal of the red bars, and the change to a much more friendly bubble type design for validation errors.
The Differences and Co-Existing
If you take the time to dig into the differences in the form patterns for 7.x you will see that there is actually only one very, very small change that is needed to take a 6.x form and make it look perfectly fine. That difference in implementation is simply a change to the object that receives the "dnnFormRequired" CSS class. In DotNetNuke 6.x you provide that class to the actual input field so that it can get the red bar. In DotNetNuke 7.x you provide that class to the label so that it can get the red asterisk.
Now, none of us want to support two different versions of a module just to support this subtle difference, so what can we do? Amazingly it is very simple, just add the dnnFormRequired class to BOTH the label and the control. If the module is used in 6.x the red bars will show up, if on 7.x the red asterisk will be displayed, allowing you the best possible solution overall.
This posting has been cross-posted to my DotNetNuke.com blog