Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

DotNetNuke Form Patterns and You! 6.x or 7.x?

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 came 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 theDotNetNuke 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 on 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 Personal Blog.


Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (22)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (270)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?