DotNetNuke Tips & Tricks

Tuesday, August 12, 2008 by Cuong Dang

Don'ts in Module Development

Filed under: Tips & Tricks

Working on many projects (both custom and commercial modules from third parties), I've often seen repeated mistakes that developers made in module development. I decided to write a short blog post to share a bit experience about dont's in module development with the hope to make the job easier for others.

1. The <br /> tag

Issue: One of the most common (bad) habits that developers do is to use <br /> tag to create padding between the two elements. This is not an ideal approach because it is troublesome to control the padding and margin of the elements for site administrators (not to mention that many are still writing the <br> tag without closing it).

The <br /> tag is not meant for creating padding or margin. It is used in separating the two sentences (not paragraph). Therefore, when somebody wishes to adjust the padding or margin, they will run into some issues. They will have to locate the control that’s being used and remove the <br /> tag and in some cases, it’s not an easy job to find especially for web designers.

Proposed Approach: Ditch the <br /> tag for margin and padding between elements, use a CSS selector instead. By taking this approach, the padding and margin between elements can be overridden from the skin.css file without having to alter the default file from the module package. When the new update package is available, they won’t have to deal with modifying the .ASCX file again.

2. Fixed width elements

Issue: Fixed width elements can be used when building a piece of software or custom module for a DotNetNuke website. It makes sense since we already know all the measurements for the layout. However, in commercial module development, the market is unknown and the design they will use is a nowhere to be able to guess. Therefore, using fixed elements for your modules will force site administrators to configure their sites to work with your module. It's not an ideal approach!

Proposed Approach: Use elastic or fluid layout instead. Using percentages or em to control the width elements will provide more flexibility and ensure that the module will work with very limited adjustment in layout. The goal is to make the module layout more generic to fit in any site design.

3. Inline CSS

Issue: Writing code that complies with W3C validation process doesn't mean that you have adopted web standards. Passing W3C validation sometimes results in poor performance and create maintenance nightmare such as the inline CSS case. Many developers like to embed inline CSS when working on their modules to get the job done quickly, hence, it results in maintenance issues and reduces productivity for others. I wrote an article explains why inline CSS is a bad practice here, you can read more about the downside.

Proposed Approach: use a separate style sheet. In this case, put everything in your module.css file so it’s easy maintenance for others. Site administrators can go in the CSS file and make some changes to it without go through the hassle of locating the right control to remove inline CSS.

If you have any other recommendations, please do share!


Wednesday, March 25, 2009 10:35 PM
Good Effort. Keep it up
blog comments powered by Disqus