During the last several months I have been doing more and more jQuery development and have found a few key tricks that have improved my code and made my development experience much more enjoyable.

1.  Inject the jQuery library reference in the head section.

jQuery does not know about the DNNMenu and the ClientAPI.  It will step all over them if given half a chance.  Of course, DNNMenu and the ClientAPI are aware of possible conflicts with popular JavaScript libraries and will take steps to avoid any conflicts IF the jQuery library is already loaded.  The ClientAPI is loaded at the top of the ASP.Net page form so loading jQuery in the header ensures it is loaded before the ClientAPI. 

If you are building a module that injects a jQuery library reference, add it in the page header and you will be safe.  If you just want to include a jQuery script on a page then you can edit the Page Settings/Advanced Settings to add the script reference to the Page Header Tags.

More...

For the last year and half I have increasingly turned to one module as my goto solution when building out new capabilities.  For me the Reports Module is proving itself to be the Swiss Army knife of the DotNetNuke module world.  With some of the features coming up in future releases of the Reports module this will become even more evident to anyone who takes the time to learn how to use the module.

So why do I feel so strongly about the reports module? It is mainly because of the architecture that Andrew Nurse put in place to allow you to create custom data sources and custom visualizers.  This architecture makes it easy to get data from almost anywhere and then to have complete control over how it is displayed. 

For most people the built in DotNetNuke Data Source, and XSLT Visualizer can handle most of your needs.  You can query any data in DotNetNuke and then use XSLT to display that data.  If you have not used XSLT before, you are missing out on a very powerful tool.  Whether it is displaying a blogroll, the MarketPlace Monitor or even building an entire eCommerce site, XSLT gives you a lot of capability to take XML data and transform it into as simple or complex a page as you can imagine.

More...

DotNetNuke 4.9.1 and DotNetNuke 5.0 included a new feature called the DotNetNuke Dashboard which is available from the Host menu.  The Dashboard provides access to numerous stats and settings from a single location which simplifies finding the information which is often needed when troubleshooting problems.

In addition to displaying critical data, the Dashboard allows the host user to export the data so that it can be easily provided to tech support if desired.  Having offered SLA support for the past year, DotNetNuke Corp staff often had to do much of this data collection using manual processes.  In speaking with many module vendors, we found that they were experiencing the same support issues.  The dashboard should greatly simplify this process.

More...

DotNetNuke 3.0 added a lot of new capabilities.  One of the little documented features was the ability to control how DotNetNuke is installed.  Over the last 4 years the installation capabilities have been expanded.  One of the features which was added was the ability to control the Host Settings during the installation process.

More...

During the OpenForce Conference, I heard from several designers that the DNNMenu had problems with Search Engine Optimization (SEO) because it rendered menu items that used JavaScript for navigation.  While I assured them that this was not the case and that the menu rendered a down-level version for search bots, I thought I would perform further testing and document the exact behavior.  In the process, I found that while the DNNMenu performed as expected, ASP.Net did not.

To observe the behavior of the menu, I used Firefox 3 with the User Agent Switcher plug-in.  This plug-in allows you to simulate any user agent string you wish.  For testing purposes you can find a complete list of user agent strings at useragentstring.com.

More...

DotNetNuke has long supported building modules as separate projects in Visual Studio.  With the release of Visual Studio 2005, Microsoft added a new compilation mode for web projects called Web Site Projects.  This required module developers to figure out how to work in the new paradigm since our previous module development methodologies would no longer work.  Anyone who was around for that transition knows how painful it was to relearn how to create modules.  The old methods no longer worked and the WSP model did not provide many of the same benefits as the compilation model in VS 2003.  Microsoft listened to the complaints of the DotNetNuke community and many other web developers who still wanted the old compilation model.  Their solution: Web Application Projects (WAP). 

WAP brought back the more traditional development style that DNN developers were used to.  Unfortunately there were some new kinks as well.  I have long advocated keeping my module projects separate from the DotNetNuke installation.  I create and destroy DNN installs quite a bit and don’t want to inadvertently delete some of my code during my frequent site purges.  Keeping my modules in a separate project directory allows me to delete websites without harming my modules.

More...

While catching up on blogs this morning I ran across a little PowerShell gem on Walking Dependencies in Powershell.  Chris outlines a problem that has popped up a few times in DotNetNuke.  Usually it revolves around CountryListBox or DotNetNuke.WebUtility.  Finding the offending assembly is always trial and error.  Chris’s solution should help resolve that issue.  I found a few minor bugs in Chris’s script which I have fixed.  The reflection call is a static method and is missing a “]::” and the Convert-Path is unneeded if you call ReflectionOnlyLoadFrom with $_.FullName (this will become important in a minute).  More...

Over the last several years web developers have moved more and more code to the browser in an effort to improve the overall user experience.  This code is usually in the form of JavaScript libraries which provide advanced functionality and improved performance.  With the widespread adoption of AJAX developers are pushing our JavaScript skills to the limits.  Even with this increased reliance on JavaScript running in the browser, there is still a need for server side application code.  While the split in application logic has brought some improvements in our user experience, it has brought its own set of challenges as well.  Having application code in two locations often requires us to pass values from the server side to our client-side JavaScript and for the JavaScript to be able to pass those values back to the server.

Jon Galloway discussed this issue and provided a generic ASP.Net solution in Getting JavaScript and ASP.Net talking (outside of AJAX).  Rick Strahl followed this up with his own solutions in Embedding ASP.Net Server Variables in Client JavaScript Part 1 and Part 2.  Both of these solutions work just fine for generic ASP.Net development.  The downside to both of these techniques is that they require you to load one more component into your application or to dig into how to implement the necessary IScriptControl interface, which Jon points out “it's a little tough to set up”.  More...

Anyone who has spent much time working with Cascading Style Sheets (CSS) has discovered that each browser has slightly different support for the various CSS versions.  To further complicate CSS usage, each browser has a different set of bugs and/or understanding of what a particular standard requires.  Internet Explorer is definitely the worst offender and the furthest from fully and faithfully supporting CSS 2.1.  While support has been steadily improving between versions, it is still not on par with other modern browsers.

Typically, designers use a number of different hacks to target CSS at specific browsers in order to work around the inconsistencies.  The process generally starts with a skin design which renders correctly in Firefox and then the designer adds hacks to get it to work in IE.  To make matters worse, Microsoft has made changes in each subsequent version of IE such that a hack that worked in IE5.5 will not necessarily work in IE7. More...

Over the last 5 years I have literally installed DotNetNuke hundreds of times on my local development machines.  During this time installation has gotten easier, but it still takes a few minutes and is still subject to mistakes being made.  Also, because there are several steps involved, I often take shortcuts.  This is ok when I am just throwing up development instances, but it is counterproductive when I am trying to do actual testing of a beta or release candidate.

Last fall I started building a series of PowerShell scripts for simplifying the process.  Although there are installers available for DotNetNuke, they are often out of date and are fairly rigid in how they perform the install.  Using PowerShell provides a lot of advantages over a traditional installation program.  I have complete control over the installation in an interactive environment and can change any one of dozens of parameters that control the installation.

More...