The Accidental Geek

DotNetNuke 5.1.0 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 23 Jun 2009 10:30:17 -0900

After more than 18 months of development, months of testing, and many, many long nights troubleshooting performance issues I am proud to announce the release of DotNetNuke 5.1.0. This release represents the future of the DotNetNuke platform and is now officially recommended for production use. While many users have been successfully running DotNetNuke 5.0 and 5.0.1 in production for many months, we feel that this 5.x release is finally mature enough that we recommend it for use in production environments. This release includes hundreds of bug fixes and dozens of enhancements and new features. Below is a list of just a few of the highlights from the 5.1.0 release. As always, you can find a complete list of changes on the

Major Highlights

Added Content Versioning and simple workflow to the HTML module.
Added Admin Console module to simplify access to administrator and host pages
Added publicly accessible skin engine lifecycle events
Added audit trails to core system tables
Added built in support for Google Analytics
Added custom sitemap priorities
Enhanced the permission system to use the provider model, allowing for custom permission providers
Enhanced caching to enable access by distributed caching systems
Enhanced installation and upgrade logic to automatically detect .Net 3.5 and to upgrade the web.config as appropriate.
Enhanced the extensions pages to show which modules are used and to show the pages where they are currently in use
Enhanced the Scheduler to show a checklist of available servers in the webfarm where scheduled tasks can be executed.
Enhanced the Scheduler to support multiple instances running on the same server
Fixed issue with removing Superuser role from a user.
Fixed issue with deleting users which was not fully recognized by the rest of the application.
Fixed issue with upgrades which would fail if .Net 3.5 was installed
Fixed issue with skins installed using the batch installer.
Fixed change to GetModulesByDefinition API method which resulted in breaking change from DotNetNuke 4.x
Fixed CloakText API method which was broken in 5.0.1
Fixed issue with stored procedure for Dashboard which would fail with an error if database account did not have permissions to the MSDB database.
Fixed issue where pages added while on a host page will not be associated with a portal.
Fixed issue where the ReturnURL for the SendPassword and Register links on the Login page were broken.

Security Fixes

none

Updated Modules/Providers

The following modules and providers have been updated in the 5.1.0 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

Forms and List 05.00.02
Announcements 04.00.03
Reports 05.01.00
Events 05.00.01

Providers

FckHtmlEditorProvider 02.00.04
AD Provider 05.00.02

DotNetNuke Tips and Tricks #11: Using jQuery in DotNetNuke

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 26 May 2009 05:26:10 -0900

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.

2. DotNetNuke 4.9.1 and above already include jQuery.

If you are using DNN 4.9.1 and above, then jQuery is already included in the distribution. The DNN 4.9.x versions will require you to add your own jQuery reference to the page, but DNN 5.x will add the reference to the page if the framework decides it is needed.

In 4.9.1+ you can either inject the jQuery using code or by using the Page Settings shown above. By default, DNN 4.9.x will use jQuery 1.2.6. If you require a newer version, then you should store your copy of the script in your module directory or in a portal directory. This will avoid some potential conflicts with other modules which may require a specific version of jQuery.

DNN 5.x will add jQuery to any page if the service is requested (see my previous jQuery post for the needed code). The DNN Widget framework, which is enabled by default, automatically registers every page. So as long as the widget framework is enabled, then you are covered. If not, have your module register the request or use the Page Settings shown above.

3. Don’t use the $ alias

One of the first things that a new jQuery user learns is the $ alias. Using $(selector) to get some page elements is a truly powerful concept. It is such a powerful concept that the $ alias is used by most of the major JavaScript frameworks. Since most of my work is in DotNetNuke, I find that it is just easier to avoid using the $ alias in my scripts. 5 extra characters seems a small price to pay for peace of mind. By staying away from the use of $ I have avoided a lot of problems.

For some people however the $ is an important feature of jQuery. Maybe they have existing scripts that they want to use and replacing all of the $ references would be too painful.

4. Wrap your jQuery in a closure to properly map the $ alias if you must use it.

For example the following jQuery code does not work in DotNetNuke:

$(function() {
    $('#box span').hide();
    $('#box').click(function() {
        $('#box span').hide();
        $('#box').css({'background-color': '#ccc'})
            .animate({ left: 500 }, 2000)
            .animate({ top: 150 }, 700, function() { $('#box').css({'background-color': '#988'}); })
            .animate({ left: 0 }, 1200)
            .animate({ top: 0 }, 700, function() {
                $('#box span').show(1000, function() {
                    $('#box').css('background-color', '#333').css('color', '#fff');
                });
            });
    });
});

Getting this function to work is easy – wrap the code in a simple function and pass the jQuery object as a parameter.

(function($) {
    //Your jQuery code here
})(jQuery);

5. Variables are overrated

One of the greatest strengths of jQuery is that it allows you to chain method calls. Most methods in jQuery return a jQuery object. Using chaining allows you to minimize the creation of temporary variables which in turn makes your code easier to read.

There are still places where variables are useful. If you are creating multiple jQuery objects using the same selector or where you might be able to use a common ancestor element to get at the necessary elements, then you can gain a performance advantage by creating a temporary jQuery object and chaining subsequent method calls off that element.

Using a cached version of the jQuery object in the above script would result in:

$(function() {
    var box = $("#box");
    box.click(function() {
        box.find('span').hide();
        box.css({ 'background-color': '#ccc' })
            .animate({ left: 500 }, 2000)
            .animate({ top: 150 }, 700, function() { box.css({ 'background-color': '#988' }); })
            .animate({ left: 0 }, 1200)
            .animate({ top: 0 }, 700, function() {
                box.find('span').show(1000, function() {
                    box.css('background-color', '#333').css('color', '#fff');
                });
            });
    }).find('span').hide();
});

This script uses a single variable but avoids four calls to the jQuery constructor to create the same object, and chaining the find operation off this common element shouldn’t result in any performance degradation.

5. The End() function is your friend

The last example forced me to change the ordering from my original script and hide the span after creating the click event handler. Sometimes ordering is important so it is useful to know how to use a common jQuery element, modify descendents and then go back and modify the parent last. This is where the end function comes in. Essentially this function reverts the jQuery matched set to the list of elements prior to your previous destructive change. Using this technique, I can keep the same ordering in my code as the first example, and still make use of a common variable (yes I do know that I could create a second variable to cache the span object but then I wouldn’t be able to show you this example ;) ).

$(function() {
    var box = $("#box");
    box
        .find('span')
        .hide()
    .end()
    .click(function() {
        box
            .find('span')
            .hide()
        .end()
        .css({ 'background-color': '#ccc' })
            .animate({ left: 500 }, 2000)
            .animate({ top: 150 }, 700, function() { box.css({ 'background-color': '#988' }); })
            .animate({ left: 0 }, 1200)
            .animate({ top: 0 }, 700, function() {
                box.find('span').show(1000, function() {
                    box.css('background-color', '#333').css('color', '#fff');
                });
            });
    });
});

6. Keep things lite

It is important to remember that all this JavaScript is not without a cost. There is a bandwidth cost to download the code to the client and there is an execution cost that the user also must pay. If you bloat up your page with too much JavaScript then it will affect the performance of the page for users running older machine or older web browsers. You should always keep the end user in mind when adding jQuery and JavaScript to the page because it has a double impact on your site performance. Just remember that in addition to your code, DotNetNuke is going to load the ClientAPI, the jQuery framework and the AJAX framework. That is a lot of JavaScript already on the page.

Where this becomes important is in the area of plugins. Often jQuery users will use a jQuery plugin because it has a lot of functionality, but if you are not using all of the functionality and you can reasonably code the needed functionality in a fraction of the code, then you are better rolling your own code and forgoing the use of the plugin. A great example of this is the jQuery UI tabs control. As I showed in my post How to create JQuery Tabs in DotNetNuke, you can build great looking tabs using very little JavaScript (about 23 lines of code plus 10 lines of CSS). Compare this with almost 13k of compressed code for the jQuery UI version of the tab control (plus 110K for the core jQuery UI library). Unless you really need all the functionality of the jQuery UI tabs and the UI library, then you are paying a huge price for very simple functionality.

Technorati Tags: DotNetNuke, jQuery

DotNetNuke 4.9.4 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Thu, 21 May 2009 01:52:03 -0900

DotNetNuke 4.9.4 is a minor stabilization release for the 4.x codebase. This release is targeted at resolving a major defect with the module caching code and also addresses two minor security issues. We do not anticipate any further releases of the 4.x codebase.

As always you can see a complete list with all the details of each fix/change in the ChangeLog.

Major Highlights in this release

Fixed a major module caching issue which resulted in empty content for webcrawlers
Improved performance of FormatRemoveSQL method

Security Fixes

Low - Errorpage information leakage
Low - HTML/Script Code Injection Vulnerability

Updated Modules/Providers

The following modules and providers have been updated in the 4.9.4 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

Announcements 04.00.03

Providers

Removed the AD Provider so that it cannot be installed by the Install Wizard. It can still be manually installed.

DotNetNuke OpenForce 09 Speakers Announced

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 19 May 2009 01:56:00 -0900

Yesterday, announcements went out to speakers who submitted sessions for DotNetNuke OpenForce North America. During the call for speakers we received almost 200 entries and 70 speakers. Obviously, everyone cannot speak and making the selections was extremely difficult. We appreciate all of the input we received which made our task both easier and more difficult. Easier in that there were lots of great topics to choose from so getting good coverage across all the tracks was relatively simple, and more difficult in that we knew that we would have to eliminate many great topics and speakers.

The selection committee members each assigned a ranking of 1 to 5 to each of the submitted sessions and the highest ranking sessions were then reviewed and discussed to come up with the final list of sessions. During this process we had to do a little balancing to make sure we had a good mix of sessions across all the tracks, but given the great list of sessions, that was a relatively painless exercise.

One aspect of OpenForce that I am proud of is that we are able to rotate in new speakers every year. This year is no exception. This year’s speaker selection includes 6 new speakers who will be speaking at their first OpenForce Event. I always enjoy the fresh perspective that each new speaker brings to the conference.

While it is important to have new speakers, it is also important to have some proven speakers as well. We have 7 returning speakers who have spoken at one of the past conferences. These speakers provide a sense of continuity year to year and always have great sessions. We are proud to have them back again this year.

In the end, we have a mix of topics and speakers that should be of interest to both beginning and advanced DotNetNuke users. I am looking forward to another great OpenForce Conference and can’t wait to share the experience with you.

Brandon Haynes
Secure Module Development: Theory, Technique, and Practice	Module Development
Track: Development, Advanced Virtually all DotNetNuke module developers know that it is important to write secure code, and that the security of a portal is highly correlated with the strength of the modules installed therein. However, fewer developers are aware of the techniques, theory, and tools that provide guidance about how to structure a DotNetNuke module so that it is maximally secure. In this session, we cover at a high level the multifaceted concept of security as it relates to DotNetNuke module development. As a theoretical backdrop, we discuss the related concepts of STRIDE and DREAD, attack trees, and encryption technologies. These techniques are then applied to module development, including discussion of some common anti-patterns and the importance of utilizing core functionality. Finally, we explore some of the tools available to developers, including static analysis, to best mitigate vulnerabilities that can be prevented at design-time.
Cathal Connolly
DotNetNuke performance tips & tricks	Administration
There’s a multitude of tips & tricks to gain additional performance out of DotNetNuke. Come along to this session to see what techniques you can see, settings you can change, and tricks you can use to squeeze as much performance out of your site as possible.
Charles Nurse
DotNetNuke in the Cloud	Module Development
At the Professional Developer's Conference in the fall of 2008 Microsoft announced its vision for the Cloud - Windows Azure. This talk will look at the components of the Windows Azure platform and how we can take advantage of Windows Azure Services in DotNetNuke.
Christopher Hammond
Creating a DotNetNuke Module for Facebook’s Open Stream API	Module Development
This session will provide you with an introduction to creating a DNN Module using Facebook’s new Open Stream API for accessing a user’s stream of Facebook information, retrieving and adding to the stream. We will develop a C# module using a Visual Studio template project accessing key information from Facebook’s API to show you a way to extend social networking onto your own website.
Cuong Dang
Advanced DotNetNuke Skinning Concepts through CSS and XHTML	Design (Skin Development)
The DotNetNuke skinning engine provides great flexibility in adapting to all sorts of design challenges. Think you can’t achieve that design within DotNetNuke? Think again! This session will cover advanced CSS and XHTML techniques used in DotNetNuke skinning which will allow you to achieve any design. We will leverage the enhanced features bundled in DotNetNuke 5.0 such as widgets to build a user-friendly web site, with minimal coding effort.
UX in DotNetNuke! Designing Your Applications the Right Way	Design (Skin Development)
Co-presenter: Ian Robinson Good user experience (UX) is not limited to an appealing user interface. It is about making an application that is easy for your users to learn and interact with. This session will explore the process of creating a good user experience from prototyping your design and user workflow through implementation. Learn the secrets to creating intuitive forms, consistent user interaction, and polished and responsive user interfaces. (if necessary, Cuong Dang can present this session alone)
Dr. Ravi Kalakota
Building Process Automation Portals with DNN	Development
As a leading global provider of human resource consulting, outsourcing and investment services, Mercer serves more than 25,000 clients globally. Increasingly Mercer is automating HR processes and delivering services via portals to clients globally. The portal solutions are architected from the outset to be on-demand, multi-tenant, highly scalable, highly secure, highly configurable and high performance, in order to rapidly deliver value to our customers. DNN is playing a key part in the overall Mercer portal strategy. In this talk, Dr. Kalakota will provide specifics into different solutions being architected using DNN.
Eric Shafer
E-commerce Options for DotNetNuke	Administration
How many ways can you skin the e-commerce cat? Well, there are a lot to say the least. From single product stores, to fully custom-developed solutions, the spectrum is daunting. This session explores the large number of solutions and provides quick guidelines to estimate scope, cost and schedule for a DotNetNuke E-commerce site. We will cover PayPal and Google Checkout, the DNN Store module, Catalook, ASPDotNetStorefront, and custom-developed solutions.
Jason Kergosien
Deploying DNN in the Enterprise	Administration
In this session, we will discuss implementing DotNetNuke in an enterprise environment, impacting all departments of a large organization with many divisions. Jason will discuss real world scenarios and best practices learned by implementing DotNetNuke as a content management system for one of the largest school districts in Dallas, TX, involving 50 web sites managed by hundreds of content managers, while maintaining standards of quality across the enterprise. We'll discuss environmental, political, and training considerations in the process.
Kevin M Schreiner
DotNetNuke on Speed and Performance	Administration
Using real world examples and proven configurations to identify the best specifications for DotNetNuke installs. Configure your site for scalability, speed and efficiency. This session discusses the performance characteristics of the core platform and ways in which you can configure web farms, servers, sites, pages and modules for peak performance. Topics include both browser and server side speed enhancements, taking into consideration each particular area and the benefits and draw backs to the caching and performance settings as well as a full breakdown of performance statistics and stress testing results.
JQuery, JavaScript and DotNetNuke	Module Development
Developers and designers now can work more effectively creating rich interactive environments through the adoption of JQuery, JSON and JavaScript class objects. Many developers who have used JavaScript in the past and have developed simplistic interactions within their sites probably have not yet learned the best practices for development of JavaScript libraries. This session will discuss the benefits and capabilities extended to you through JQuery, followed by a set of development samples of using JQuery to add interaction into your DotNetNuke sites. Additionally it identifies the correct approach for developing class libraries for JavaScript and proven best practices for developing rich JavaScript libraries for your skins and modules.
Marian Dumitrascu
Bring SharePoint Intranet to Your DotNetNuke Extranet Portal	Module Development
Many medium to large corporations choose SharePoint for their Intranet needs. However, many of them struggle to make it available for their extranet presence. This presentation will demonstrate how to expose SharePoint lists and document libraries into a DotNetNuke module.
Panel Discussion
DotNetNuke in the Enterprise	Administration
DotNetNuke has gained extensive adoption in small businesses and is increasingly being used by large enterprises to address some of their unique concerns. We'll talk with several panelists from large corporations and see some of the unique challenges they face and how they were able to leverage DotNetNuke to address these challenges.
Mitchel Sellers
Getting the Best Performance Out of DotNetNuke	Administration
This session covers the role of the DotNetNuke site administrator in proper site performance. A comparative analysis is completed showing baseline and optimized site performance in many traditional settings. Included in this session is recommended configurations for Shared, Cloud, Virtual and Dedicated installation environments. All using proven configurations that have been perfected by the presenter. The session finishes with a checklist of routine maintenance items that should be completed on a regular basis to ensure that site performance remains top-notch.
Peter Donker
Content Localization in DNN	Module Development
DNN does very well with 'static localization'. This means all fixed texts in the application. As a result you can use DNN to roll out a site in any language you like. But what if you want to have a site in multiple languages? Do you create multiple portals? Or are there better ways to do this? This presentation looks at the latest developments in content localization for DNN. We will examine existing solutions and the direction DNN will take to help you deliver multilingual content.
Steve Fabian
WCF and DotNetNuke	Module Development
This session will show you how to write a WCF Service to access/expose your DotNetNuke data. WCF can be intimidating, but this session will take you past the complexity and show you how easy it is to setup a WCF service and expose both a SOAP and a REST endpoint. Then we'll build a Windows Application that allows you to retrieve some site metrics using your new WCF service. And finally, we'll build an offline editor that will allow you to modify the content of your web site from a Desktop Application using the WCF Service.
Windows Workflow and DotNetNuke	Module Development
This session will show you how to use Microsoft's Windows Workflow Foundation in your custom DotNetNuke modules. We will talk about WF, how to define a workflow, your options for hosting the Workflow Runtime, and how to use your workflow to implement business rules in your custom DotNetNuke module. We'll also show you how to build a library of custom DotNetNuke Workflow Activities that you can use in your workflows. NOTE: This is a developer presentation .. Yes .. There will be Code.

Another Milestone for DotNetNuke Corp.

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Mon, 18 May 2009 05:15:00 -0900

As many people already know, I spent the past week traveling to California and Canada to meet with the DNN Corp. management and engineering teams. This was an exciting trip for me as it was a chance to see us reach one more milestone in the growth of DotNetNuke and DNN Corp. For the last 6 years, DotNetNuke has been a virtual organization with core team members spread around the globe. This is the norm for most Open Source projects and while it poses some challenges, it is something you learn to deal with if you want to be involved. When Shaun, Scott, Nik and I formed DNN Corp in 2006, we continued operating in this fashion. We each had our own home offices along with Charles Nurse and Bill Walker.

Starting in January DNN Corp began hiring additional employees. It is no longer possible for everyone to work from home or to work from temporary office spaces and we began the search for office space. As anyone who has been through the process can tell you, it can sometimes take a while to find suitable office space and get it built out and ready for employees. In April we finally moved into new offices in both San Mateo, California and Abbotsford, British Columbia. This trip was my first opportunity to visit the new offices and meet some of our new employees.

Our California office is the home for our sales, marketing and admin staff along with some of our management team. Located in San Mateo, this office is easily accessible from the San Francisco Airport. It is a nice modern facility. Unfortunately, we are almost out of space and will soon need to look for supplemental space to handle our overflow. Just one of the many challenges of working in growing company.

Our California Office

Michelle Baca – Corporate Accounting Manager. The most powerful person in any company (she makes sure we get paid) ;).

Terry Erisman – Director of Marketing. He tries to keep us all on the same page with a consistent message. A tough job in any company.

Alex Pringle – Sales Account Executive. He keeps the engineering team focused by letting us know what the customers want – an invaluable part of the product feedback loop.

There are many other individuals working out of our San Mateo office who likewise contribute to the overall success of the company, unfortunately they were out of the office when I finally remembered to pull the camera out. Some of them might say that is a good thing ;).

After leaving California, I headed up to Abbotsford, British Columbia, Canada for a few days to work with the engineering team. We are hard at work putting the finishing touches on the DNN 5.1 Community and Professional Editions. For those who are not aware, Abbotsford is located near the US-Canadian border about an hour East of Vancouver. It is also where Shaun lives. Scott Willhite also came up for a few days – of course I monopolized a bunch of his time

Since Abbotsford is a small town, you won’t find any massive glass office towers, but it definitely has the better view of either office location. Being located on the edge of the Cascades and Rocky Mountains, you are guaranteed to have scenic mountain views almost anywhere you go in Abbotsford, and our offices there are no exception.

It was exciting to see our logo on the office door for the first time.

John Lucarino – Software Engineer – Hard at work on an exciting new project.

Even though it was overcast that day, the Rockies are clearly visible in the background. What an awesome view out of the office windows. It is views like this that make me miss living in the Pacific Northwest. Who knows, maybe a home in Abbotsford is in my future.

After a long week of visiting the new offices I had a big surprise when I returned home this weekend. My wife had cleaned up my home office. It was just like walking into a new office. Trust me when I say that you would not want to see what it looked like when I left for the week.

My Home Office – after a major cleanup effort from a loving wife. What a great way to end a trip.

It’s Vegas Baby!

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Fri, 08 May 2009 02:57:54 -0900

Once again the DotNetNuke community will be heading off to Las Vegas in November for the annual DotNetNuke OpenForce North America conference. We are looking for a handful of people who want free hotel accommodations and conference admission. All you have to do is get selected to be a speaker. You know you have a lot of great insight and knowledge of DotNetNuke and would love to share it with the DotNetNuke community. Well today is your last chance to turn in your speaker submissions for the North American conference. Just go to the OpenForce homepage at http://www.openforce09.com and follow the directions but you better hurry before time runs out.

I Spose I’ll Just Say It: Still Waiting For a GOOD Reason to Learn MVC

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Thu, 23 Apr 2009 05:35:00 -0900

Why you shouldn’t learn MVC

Earlier today Rob Connery posted about why he thinks You Should Learn MVC. Rob is a great guy and we always have lively discussions whenever we meet at conferences. I was in the middle of writing a long comment on his blog when I decided it might be better as it’s own post.

I have to say Rob, once again, another great post! Another great use of straw man arguments and red herrings. Come on really? You are going to trot out jQuery as a reason to try MVC? Why not say “Use MVC because it runs on Windows and works with IIS”. Come on, at least use real arguments if you are going to make the case for MVC. I’m sure you know that jQuery works wonderfully with WebForms. People like Rich Strahl, Dave Ward and others have a ton of great blog posts on the topic. I even have a few myself. jQuery is a valid argument if you are trying to sell people on adding more JavaScript, but the argument as framed does not make the case for MVC.

Wow. You can use your own view engine in MVC. Good to see that MVC didn't break a basic feature we have had in ASP.Net since the 1.0 days. Nobody using ASP.Net is forced to use WebForms for page rendering. It seems that in Rob’s world, projects like Umbraco, Castle, and Visual Web GUI are the only people smart enough to figure that out. It is perfectly valid for a page or a control, or heaven forbid an HttpHandler, to use a different rendering engine for generating the HTML.

Non-validating Html - Really, that is the best you have? To paraphrase a quote from Rob - "Non-validating HTML is as Non-validating HTML does". If you want to write code that validates in WebForms, that is completely possible today. If you don’t care whether your page validates then moving to MVC isn’t going to make you suddenly start caring. I can throw a div inside a span and use capital letters in my attribute names and even use the bold tag and MVC will merrily spit it out to the browser. Sure, WebForms has a ton of crappy controls that will render garbage, but that is not the fault of WebForms. It is the fault of the control developers and the people who use those controls. There are lots of controls that render great markup – and people who care about their markup will either use a good control, or hand code their html.

Amazing, you can use IoC with MVC. Wow. I wish you could do that with Asp.Net and web form apps. It's is mind-blowing that all these IoC containers were written before MVC came along. Like they just knew that possibly someday, someone would be able to use them, if only MS would create a different web framework - or rather slap a different front end on ASP.Net. I guess I better stop using IoC with my webform apps since it is not possible.

I must say I agree with you about WebForms being one giant pile of abstractions, and frankly I am tired of it. Enough already. Let's get rid of these damned abstractions. Why, here I am using these alphanumeric characters, when we all know that it is just an illusion, a sham a hoax. There is no such thing as a character to a computer. There is only 1 and 0. Wait... that's not right either. There is only some voltage level that is not 0 and 0. or maybe it is 2 different magnetic orientations, or a pit and the absence of a pit. Whatever - I digress. We live and work in a world of abstractions. All of computer science is about abstractions. Rob has climbed the Mt Everest of abstractions and declared that one tiny snowflake sitting on the top is bad and must be replaced. You have suddenly declared that the top floor in our Tower of Babel is faulty and that this new penthouse suite is suddenly the one true path to heaven.

As for me and thousands of other ASP.Net developers, we are quite satisfied with our current abstraction. It makes it easy to do a lot of tasks. If I find the abstraction too leaky in places, then I push the abstraction out of the way and roll my own. Is this any different than what Chad and Jeremy did with FUBU MVC? But in most cases, I don’t need to go quite that far. I am quite comfortable writing an HttpHandler or an HttpModule for those cases where the webform defaults are getting in my way. I don’t require a whole new framework and a whole new mindset to get things done. I can use WebForms where they make life easy and dive down in the weeds when I really need fine-grained control.

Hey look at those nice URLs they generate in MVC. Boy, those are slick. No, really, they are. I’m not being sarcastic or anything. You really should check them out. But you know what – you can have them in WebForms as well. Scott Allen has a great MSDN article that discusses this very topic.

So enough already of the red herrings, the straw man arguments and the downright deceptive use of facts. How about a real argument about using MVC that doesn't first assume complete web illiteracy on the part of ASP.Net developers, but that somehow, if they use MVC those same brain-dead developers will suddenly become programming geniuses. If they were afraid to use jQuery before, they won’t use it just because they are in MVC. If they didn’t care about testing or HTML or clean URLs, MVC is not going to make them see the light. MVC is a tool. Good at some things, bad at others. In the hands of a master it will do great things. In the hands of someone who doesn’t care about his craft then MVC will be a nice diversion and yet another excuse for creating bad code.

So, lest you think I am against MVC, let me assure you I am not. I am against all of the same ol’ tired excuses about why people should jump to MVC. Every abstraction is about making tradeoffs, and make no mistake about it – MVC is an abstraction. Some people will claim it is a good abstraction, others will disagree, but at the end of the day the MVC team had to decide what was most important to them. Testability was clearly high on the list (Of course if you listen to Chad and Jeremy, it wasn’t high enough on the list). Clean URLs and a more restful like interaction was also important. Hiding the stateless nature of the web and leveraging reusable components – not so important.

So why should you at least learn MVC?

It will expose you to a different architecture. MVC definitely has its place – whether you are talking about desktop apps or web apps. MVC leads you to think about keeping a clean separation between different application concerns. It however doesn’t force you to do so. It is still possible for you to completely violate those rules, but it at least starts you out on the right path. WebForms on the other hand does not impose or suggest any such constraints. It is easy to get in trouble if you are not careful.

You will be forced to become intimately familiar with HTML and HTTP. This is great if you don’t already know it. I am a big believer in understanding how things work. However, for those that already have a good grasp of HTML this is a little overkill. I have a decent understanding of how the engine in my car works, but I don’t want to have to put it together every-time I want to drive somewhere. I trust the auto manufacturer to create the proper level of abstraction for me. I know what HTML is supposed to look like, but I don’t want to remember exactly which attributes can be used for a dropdown list. What events are available to me and how that data is returned. If I can abstract that away, it is a good thing.

MVC promotes unit testing. It is designed as much as possible, to get out of the way and make testing simple. This is not the case with WebForms. In WebForms, it is possible to do testing, but it will take some effort. Is that enough to get you to give up some of the abstractions that WebForms provides? For me it is not. That may change in a couple years, but I suspect that instead what will happen is that MS will invest some time in addressing this issue in WebForms. The ASP.Net team learned a lot during the development of MVC and I know that they are already working on incorporating some of this knowledge back into the WebForms platform.

MVC will make you see how much you take for granted with WebForms. I recommend that everyone should live outside their home country for a little while. You will either learn to appreciate where you are from or you will find out that the grass is truly greener on the other side. In either case, you will come out ahead. I have had the privilege to have worked in many different development environments and programmed in many different languages. I appreciate the tools I have chosen because I have seen what else is available. I can articulate why I like VB over C# and why I like ASP.Net over J2EE. But I still think it is healthy to keep looking at alternatives. In the end it will make you a better coder.

So in summary, you really should checkout MVC. But not for the reasons Rob articulated. You should explore MVC because in the end you might just learn something that will make you a better web programmer, no matter what platform you choose.

Calling all Speakers – DotNetNuke OpenForce Wants You!

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 21 Apr 2009 05:00:00 -0900

We are once again in the heart of the planning season for DotNetNuke OpenForce. It is that time of year when we ask all of you to submit your session abstracts for this years OpenForce North America conference. I know that the last 2 years, we have had great response from our community and I expect that this year will be no different.

Like the last two years, we are accepting session submissions in 4 different topic areas: Development, Design, Administration and Open Source.

Development – These are basically session dealing with code. Whether it is topic on module development or building custom providers or dissecting the internals of DotNetNuke, anything that would appeal to the software coders is fair game.

Design – This topic area is targeted at the web designers. This goes beyond just talking about skins. It also includes topics like SEO, and accessibility and can even include Localization. These sessions should focus more on the aesthetic and usability aspects of building a DotNetNuke website.

Administration – This topic area is where speakers present sessions that address the needs of the end user. How do they install DotNetNuke, how do they configure it for a Web Farm or to run in the cloud(this is different that writing a module that uses cloud services), how can they improve site performance. These sessions really focus on the day to day use and administration of running a DotNetNuke website. This topic area is also a catchall for any business related topics.

Open Source – This final topic area is designed to show attendees how they can incorporate other Open Source tools into their development, design and administration tasks. It might be a topic on using XUnit for testing or using GIMP and Paint.Net for creating your skin elements. The idea here is to expand the attendees view of the Open Source community and to bring in fresh and complimentary ideas from other Open Source projects. These sessions should still be relevant to DotNetNuke in a very meaningful way. A topic showing all the wonders of using Wordpress for blogging is not appropriate.

Frequently Asked Questions.

Q. What are good topics?

A. This is a hard question to answer since we often don’t have a standard list of topics we want to see. Each year when we sit down to evaluate submissions we try to strike a balance. We want to have a few beginner topics like basic skinning and basic module development, some intermediate level topics like adding jQuery to your module or developing XHTML compliant skins. Finally we’ll look for advanced topics like a deep dive on the DotNetNuke installer or using the 960 Grid System for skin development. In addition to balancing the level, we’ll also try to make sure we have good coverage across different technology and web design trends. These are much more subjective since there are so many great complimentary technologies. In the past we have had sessions covering topics like Security, Silverlight, Unit Testing, Accessibility, Menu controls, AJAX, PowerShell, High Availability and scalability, Localization and Globalization, Continuous Integration, Subsonic, Web standards, LINQ to SQL and SEO. The key is that we look around at what is happening in the web development space and try to pick sessions that we think are current and relevant. Attendees are just like the rest of us – they see some new technology or new trends like Entity Framework, Cloud Services (Azure, Mosso, EC2), CSS Layouts (YUI, 960, etc), jQuery, Mega-Menus and many more, and the attendees want to find out how they can incorporate these technologies into their own sites running on DotNetNuke.

Q. Who Should Submit?

A. Are you a DotNetNuke expert? Do you like to share your DotNetNuke knowledge with the community? Do you enjoy speaking in front of large crowds? You are exactly the person we are looking for.

Every conference relies on the quality of its speakers and as proven last year, the DotNetNuke community has a lot of great speakers. While we anticipate that some core team members will want to speak, we are also interested in having speakers from the broader DotNetNuke community as well. So please don't hesitate to offer your speaking services. Even if you didn't get selected to speak last year, please submit sessions. We hope to rotate in some fresh faces and give a few more speakers the opportunity to present.

Q. How do I Submit my Sessions?

A. This call for speakers is specifically targeted at OpenForce North America. We will have a separate call for speakers for OpenForce Europe.

To submit your sessions, Login to the OpenForce09 site and then go to the Call For Speakers page.

Q. What do I get if I am selected to speak?

A. Every speaker at the DotNetNuke OpenForce North America conference will receive 4 nights of lodging at the Mandalay Bay Casino and Hotel along with free conference registration. Conference registration will allow every attendee full access to the expo hall, and all sessions at the DevConnections and DotNetNuke OpenForce conferences. (Pre and Post conference training days are not covered in the complimentary registration).

Q. When and where is the Conference?

A. This years conference is being held in Las Vegas, Nevada at the Mandalay Bay Hotel and Casino from November 10th through the 12th. There will also be pre-conference and post-conference workshops available.

Additional conference details will be posted on the OpenForce 09 website as they become available.

Technorati Tags: DotNetNuke, OpenForce

Polyglot Programming: Death by a thousand DSLs

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Wed, 01 Apr 2009 09:36:15 -0900

In 2006, Neal Ford wrote a blog post on the topic of Polyglot Programming which foresaw a future where applications will be increasingly built using multiple general purpose languages and domain specific languages. Ted Neward has a recent article from MSDN Magazine which follows up on this theme with a discussion of Polyglot Programming in .Net. Both Neal and Ted address some of the issues with Polyglot Programming, but I think there is one that they have missed. Polyglot Programming can quickly lead to performance rot in application development.

In DNN Tips and Tricks #10, I presented an example of how you can use the DotNetNuke Report Module to display you data using the advanced capabilities of XSLT. Greg Lahens pointed out an issue with my SQL code which is really highlights one of the downsides to Polyglot Programming. As programmers, we often employ a variety of tools to solve a particular programming challenge. Many of these tools are DSLs – XSLT, SQL, CSS, HTML are just a few of the many DSLs in common use throughout the web development world.

The problem comes into play in that few developers have the luxury of being an expert in every DSL they use. Most developers I know, are extremely proficient in their primary language – whether it is C#, VB, Java, Ruby or whatever. Those same developers will often have a working knowledge of the secondary languages and DSLs used in their day to day programming. Yet the number of DSLs is rapidly expanding. We have DSLs for styling applications (a different one depending on whether it is Silverlight/WPF or Html), a DSL for transforming data, a DSL for querying data (possibly multiple DSLs for a single depending on how much you trust your ORM), a DSL for searching some text element, and even a DSL for merging our data with our presentation structure and styles, and several DSLs for exposing our data in a raw format to users. After learning all those DSLs, I then have a handful of additional DSLs to learn to build my application, package it into an installation package, and possibly one more for building the Help files. Ohh wait. You are doing automated unit testing right? You’ll need another couple of DSLs for that. And let’s not forget the DSL that we use for configuring the application after it is deployed.

I don’t know about other programmers, but I am drowning in DSLs. It is hard enough keeping up with my primary development language and the associated platform APIs, but these DSLs are going to be the death of me. The end result is that I have a pretty decent handle on maybe 3 or 4 of these DSLs but rarely do I have the requisite knowledge to make the right choices in anything beyond that. Yes I know SQL. But as Greg Lahens pointed out in my last post, it leaves a lot to be desired in terms of performance.

Now some might argue that SQL should be handled by a DBA who specializes in SQL. That is great. I know have 14 DSLs instead of 15 to learn. Oh wait. Sorry, I have just been informed that we don’t have a budget for a dedicated DBA. So I guess the requests for dedicated XSLT, CSS, and Regex developers probably are not going to be approved either. In most of the development shops I have worked in, the developer has no choice but to learn many of these DSLs. Most projects are not large enough to warrant the use of specialists, however almost every project demands great performance and minimal bugs. One false move in your CSS, XSLT, Regex, JavaScript, SQL or any of the other DSLs in use and you will severely impact the performance of your application.

What is worse is that the methods and tools used for testing performance in each DSL is often vastly different. I have great tools to help me profile my VB/C#/Java code. Not so much when it comes to CSS, JavaScript, XSLT or many of the other DSLs in use. And even when good profiling tools exist, learning to use them often requires a significant time investment.

I don’t know the ultimate solution to this problem, but I do know that every day it is only getting worse. The Computer Science community is cranking out languages and DSLs at a rapid pace. On top of that we continue to evolve our development methodologies and architectures such that the average programmer is left wondering how they can possibly keep up. Sure, the alpha geeks among us will be able to grok it all and crank out applications using the latest DSLs, but the average developer (who make up the vast majority of the programming resources building application today) is being marginalized more and more. I believe that DSLs have their place and certainly provide a lot of value, however we need to take a hard look at where we are going in this profession. I believe we need to find solutions that meet programmers “where they live” and not “where we want them to be”, by this I mean we need to find solutions to our CS problems that recognize that not all programmers are computer scientists. Not all programmers have the time or motivation to learn 15 different DSLs just to create an application. Not all programmers want to learn a new programming methodology because the old methodology is no longer en vogue. We need to simplify what we are doing so that it doesn’t take an army of specialists to build a decent application.

DNN Tips and Tricks #10: Reports Module

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Fri, 27 Mar 2009 07:09:00 -0900

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.

Right now there are three core modules with extensive XSLT capability built in: Forms and Lists, XML, and Reports. Forms and Lists is a great module, but it forces you to store data in the tables it defines. XML also has great XSLT functionality, but it only handles XML that is stored in a file or that is retrieved from a URL. If I want to report on Data, no matter where it is stored, my only option is the Reports module. The Reports module includes a custom data source that allows you to read UDT data, and it wouldn’t be hard to write a custom data source to read an XML file.

Even though I love the Reports module, the Forms and Lists, and the XML modules both have some features that are not currently supported by the XSLT engine in the Reports module. They all have their place in your DotNetNuke arsenal.

So if your need is just to display some data on the page, and you want something more than a simple table, then the Reports module is the tool for you. In the rest of this post I’ll walk through a recent requirement I had for our company intranet.

One common requirement in many intranets is that it should be easy for employees to find out basic contact and organizational information on other employees. DotNetNuke includes much of this information in the default user profile. For my purposes I wanted to display the following pieces of employee information:

Name
Photo
Job Title
Department
Manager
Phone Numbers (Work, Cell, Fax)
IM
Email
Location (Region, Country and Time Zone)

With my data elements identified, I can use the built in User Accounts screen to access the Manage Profile Properties page. From here I can add any profile elements I want to capture. The default set of profile elements cover most of my requirements, and it is easy enough to add any fields which are missing. Now employees can edit their own profiles and we’ll use the reports module to display those profiles.

To configure the reports module, you will need to be logged in with a Host account. The reason for this requirement is that the SQL query we are building could potentially access any data in the database. In a multi-portal environment you wouldn’t want one admin access data for another portal to which they didn’t have access. Since hosts have unlimited access to all data in the system, they are needed for defining the data source. Once the data source is defined then any user with edit permissions will be able to configure the visualizer.

Go to the module settings page and navigate down to the Data Source Settings section. For our example, I can use the DotNetNuke Data Source which uses the default dataprovider defined in the web.config. Then I enter my query. Finally, I will use the Show Xml Source link to display the resulting XML from my data source query. I will save this xml to a separate file so that I can test my XSLT during development.

Notice in my query that I just select all of the data from a custom view. You will not have this view on your DotNetNuke installation. One limitation I found very early with the Reports module is that it stores all of its configuration data in the ModuleSettings and TabModuleSettings tables. This limits the amount of text I can use for the query. I know from experience that querying profile data can get very complex and will easily exceed the size limitation of the settings tables. As a result I almost always create a custom view or stored procedure for my query. Because each piece of profile data is stored in a separate row of the UserProfile table, we have to do a join between the User table and UserProfile table for each property we want to include. As you can see from the query below this quickly becomes quite long, although most of the logic is just repeated over and over.

SELECT     
    u.UserID, 
    u.FirstName, 
    u.LastName, 
    u.Username, 
    u.Email, 
    u.DisplayName, 
    up1.PropertyValue AS Region, 
    up2.PropertyValue AS Country, 
    up3.PropertyValue AS Telephone, 
    up4.PropertyValue AS Cellphone, 
    up5.PropertyValue AS IM, 
    up6.PropertyValue AS JobTitle, 
    up7.PropertyValue AS Manager, 
    up8.PropertyValue AS Department, 
    up9.PropertyValue AS Fax
FROM
    dbo.Users AS u INNER JOIN
    dbo.UserRoles AS ur ON u.UserID = ur.UserID INNER JOIN
    dbo.Roles AS r ON ur.RoleID = r.RoleID AND 
    r.RoleName = N'Employee' LEFT OUTER JOIN
    (SELECT     
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'Region' AND 
        ppd.PortalID = 0) AS up1 ON u.UserID = up1.UserID LEFT OUTER JOIN
    (SELECT     
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'Country' AND 
        ppd.PortalID = 0) AS up2 ON u.UserID = up2.UserID LEFT OUTER JOIN
    (SELECT     
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'Telephone' AND 
        ppd.PortalID = 0) AS up3 ON u.UserID = up3.UserID LEFT OUTER JOIN
    (SELECT
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'Cell' AND 
        ppd.PortalID = 0) AS up4 ON u.UserID = up4.UserID LEFT OUTER JOIN
    (SELECT
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'IM' AND 
        ppd.PortalID = 0) AS up5 ON u.UserID = up5.UserID LEFT OUTER JOIN
    (SELECT
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'Job_Title' AND 
        ppd.PortalID = 0) AS up6 ON u.UserID = up6.UserID LEFT OUTER JOIN
    (SELECT
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'Manager' AND 
        ppd.PortalID = 0) AS up7 ON u.UserID = up7.UserID LEFT OUTER JOIN
    (SELECT
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'Department' AND 
        ppd.PortalID = 0) AS up8 ON u.UserID = up8.UserID LEFT OUTER JOIN
    (SELECT
        up.UserID, 
        up.PropertyValue
    FROM
        dbo.UserProfile AS up INNER JOIN
        dbo.ProfilePropertyDefinition AS ppd ON 
        up.PropertyDefinitionID = ppd.PropertyDefinitionID AND 
        ppd.PropertyName = 'Fax' AND 
        ppd.PortalID = 0) AS up9 ON u.UserID = up9.UserID

Now that we have our data in an xml format (you did remember to use the Show XML Source and save the output to a file, didn’t you) we can turn our attention to defining our XSLT. Because our final output is html, I like to mockup my output in a web editor. This makes the XSLT much easier, as editing HTML when you have a bunch of XSLT logic interspersed can get a little tricky depending on the complexity. Using Expression web I am able to quickly mockup a simple display using the elements previously described.

As you can see in the HTML and CSS below, it is not too complicated (and it doesn’t use any tables).

<div class="employee">
    <img alt="No Photo Present" height="100" src="No.Photo.jpg" width="75" />
    <div class="organization">
        <h2>Joe Brinkman</h2>
        <p class="title">Technical Fellow, Co-Founder</p>
        <p><span>Department:</span>Engineering </p>
        <p><span>Reports to:</span> Shaun Walker</p>
    </div>
    <div class="contact">
        <h3>Contact Information</h3>
        <p><span>Work Phone:</span> 555-1212</p>
        <p><span>Mobile Phone:</span> 555-2121</p>
        <p><span>IM:</span> <a href="mailto:joe.brinkman@tag-software.net">joe.brinkman@tag-software.net</a></p>
        <p><span>Location:</span>&nbsp; OH, United States</p>
    </div>
</div>

.employee 
{
    padding: 10px;
    border: solid 1px silver;
    margin: 10px;
}
.employee .organization {
    float: left;
    width: 275px;
}
.employee .contact {
    float: left;
    width: 350px;
}
.employee img {
    float: left;
    margin-right: 10px;
}
.employee h2 {
    font-size: 1.2em;
    margin: 5px 0px 5px 0px;
    color: #800000;
}
.employee h3 {
    font-size: 1.1em;
    color: #333;
    margin: 5px 0px 5px 0px;
}
.employee p {
    margin: 0px;
}
.employee p.title {
    font-style: italic;
    margin: -5px 0px 10px 0px;
}
.employee span {
    display: inline-block;
    width: 120px;
    text-align: right;
    padding-right: 5px;
    font-weight: bold;
    color: #808080
}

Now we are ready to create our XSLT. We know what our HTML should look like and we’ll be able to do a quick test as we go to ensure that everything is working correctly. Visual Studio 2008 includes pretty decent XSLT support, but you can use whatever editor with which you are comfortable. I used to use XMLSpy from Altova, but have found the XSLT support in VS 2008 meets most of my needs.

Using my HTML as a template, I am able to quickly put together the XSLT below. Because my final output is going to be HTML, I indicate that in the XSL:Output tag. Then I do a quick match on all elements in “//DocumentElement” which is my root document element. I use this template because I have some html which should only be included on the page one time (the root element by definition only appears once). From there I apply another template for all of the QueryResults nodes in the XML document. You will have one node for each record returned by your query. This second template is where I insert my HTML snippet.

In the QueryResults template it is a simple matter to replace all of the static data in my sample HTML with an <xsl:value-of select="ElementName" /> tag. You can see my first cut at the XSLT below.

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl" >
    
    <xsl:output method="html" indent="yes"/>

    <xsl:variable name="baseDir">http://extranet.dotnetnuke.com/portals/0/Employee</xsl:variable>
    
    <xsl:template match="//DocumentElement">
        <link href="{$baseDir}/employee.css" rel="stylesheet" type="text/css" />
        
        <xsl:apply-templates select="QueryResults" />

    </xsl:template>
    
    <xsl:template match="QueryResults">
        <div class="employee">
            <img alt="No Photo Present" height="100" src="{$baseDir}/No.Photo.jpg" width="75" />
            <div class="organization">
                <h2>
                    <xsl:value-of select="DisplayName" />
                </h2>
                <p class="title">
                    <xsl:value-of select="JobTitle" />
                </p>
                <p>
                    <span>Department:</span>
                    <xsl:value-of select="Department" />
                </p>
                <p>
                    <span>Reports to: </span>
                    <xsl:value-of select="Manager" />
                </p>
            </div>
            <div class="contact">
                <h3>Contact Information</h3>
                <p>
                    <span>Work Phone:</span>
                    <xsl:value-of select="Telephone" />
                </p>
                <p>
                    <span>Mobile Phone:</span>
                    <xsl:value-of select="Cellphone" />
                </p>
                <p>
                    <span>MSN IM:</span>
                    <xsl:value-of select="IM" />
                </p>
                <p>
                    <span>Location:</span><xsl:value-of select="Region" />, <xsl:value-of select="Country" />
                </p>
            </div>
            <p style="clear:both;"> </p>
        </div>
    </xsl:template>
</xsl:stylesheet>

If you understand the HTML from my original template then the XSLT should be pretty straight forward. Now that I have the XSLT complete I can use Visual Studio to show me the sample rendering. Select the Show XSLT Output from the XML menu.

Visual Studio will ask you for an XML file to use – you should select the XML file with the data we created earlier from our data source. Visual Studio will now render the HTML output. If everything goes correctly you are done. If the display is not exactly what you want then you can tweak the XSLT until everything is perfect. To help with this, Visual Studio allows you to debug the XSLT. This means you can set break-points and examine different values as you step through the XSLT. While that is probably not needed in this case, when you get into more complex pages, you will certainly appreciate this feature.

In this example I have left out some of the data elements and I haven’t included any complex logic. If this is your first time with XSLT then I definitely recommend that you start with something easy like the above example. With a little experience you will find that XSLT is a pretty full-featured language. There are some idiosyncrasies to get used to, but once you get into it, you will be amazed at the power and flexibility it provides.

The next version of the Reports module includes support for XsltExtension objects. This basically allows you to call custom .Net code from inside your XSLT. This means you could apply custom business logic in your XSLT that would be impossible to do in XSLT or SQL alone. You could do something like custom filtering of the displayed data based on the current user’s permissions. You could call a webservice in a custom extension and then merge the data with the rest of the data being displayed. You could do browser sniffing to determine how best to format the HTML output. With XsltExtensions you really remove any limitation imposed by the original DataSource or the XSLT language.

Now that you have the final XSLT, you can configure the XSL Transformation Visualizer. In this case I have uploaded my Employee.xsl file and left the rest of the settings with the default values. Depending on your data, you might need to do HTML Encoding or Decoding. Once everything is working correctly, you should definitely enable caching as well.

If you have been following along you should now end up with a display something like the one below. You can substitute your own “nophoto” picture and set the baseDir in the XSLT, but everything else should work without any difficulty.

At this point I hope I have shown you some of the power of the Report module when combined with the XSLT Visualizer. I will leave it as an excercise to the reader to figure out how to handle sorting and paging and how to determine the photo to display. There are several solutions you can choose depending on your skill and creativity. For more help on XSLT and XPATH I highly recommend www.w3schools.com. It has just enough information to give you a strong foundation without overwhelming you. I would definitely be interested to see how you are using the Report module or other XSLT based solutions in your own websites.

UPDATE:

After reading Greg Lahens comment I went and did some research to improve my SQL. I found a great article on Cross tabs and Pivots on SQLServerCentral.com (may require registration). Below is a Query which is much more optimized over the previous version. While there are still a few minor tweaks that could be done, those tweaks would not significantly improve performance and would require the use of SQL 2005+, so I decided to stick with a simple cross-tab query. This query dropped the number of reads to one fifth the amount over the previous query (for a small dataset) and as Greg points out, this version is much more readable and maintainable.

SELECT
    u.UserID, 
    u.FirstName, 
    u.LastName, 
    u.Username, 
    u.Email, 
    u.DisplayName, 
    upd.Region, 
    upd.Country, 
    upd.Telephone, 
    upd.Cellphone, 
    upd.IM, 
    upd.JobTitle, 
    upd.Manager, 
    upd.Department, 
    upd.Fax
FROM 
    dbo.Users AS u INNER JOIN
    dbo.UserRoles AS ur ON u.UserID = ur.UserID INNER JOIN
    dbo.Roles AS r ON ur.RoleID = r.RoleID AND r.RoleName = N'Employee' LEFT OUTER JOIN
(SELECT     
    up.UserID, 
    MAX(CASE WHEN ppd.PropertyName = 'Region' THEN up.PropertyValue ELSE '' END) AS Region,
    MAX(CASE WHEN ppd.PropertyName = 'Country' THEN up.PropertyValue ELSE '' END) AS Country,
    MAX(CASE WHEN ppd.PropertyName = 'Telephone' THEN up.PropertyValue ELSE '' END) AS Telephone,
    MAX(CASE WHEN ppd.PropertyName = 'Cell' THEN up.PropertyValue ELSE '' END) AS Cellphone,
    MAX(CASE WHEN ppd.PropertyName = 'IM' THEN up.PropertyValue ELSE '' END) AS IM,
    MAX(CASE WHEN ppd.PropertyName = 'Job_Title' THEN up.PropertyValue ELSE '' END) AS JobTitle,
    MAX(CASE WHEN ppd.PropertyName = 'Manager' THEN up.PropertyValue ELSE '' END) AS Manager,
    MAX(CASE WHEN ppd.PropertyName = 'Department' THEN up.PropertyValue ELSE '' END) AS Department,
    MAX(CASE WHEN ppd.PropertyName = 'Fax' THEN up.PropertyValue ELSE '' END) AS Fax
FROM          
    dbo.UserProfile AS up INNER JOIN
    dbo.ProfilePropertyDefinition AS ppd ON up.PropertyDefinitionID = ppd.PropertyDefinitionID and ppd.PortalID = 0
Group By up.UserID) as upd on u.UserID = upd.UserID

Fit in February – Final Results

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Wed, 11 Mar 2009 08:06:00 -0900

During the month of February I joined the FitFeb program in an effort to improve my overall fitness. My goal was to get down to 200 lbs by the end of the month. I fell short of my goal, but still made good progress. Overall, I ended the month at 210 lbs – down 9 lbs over the course of the month. That is a significant accomplishment given that I had significant travel time during the month which makes it difficult to stay on track. This also means that since New Years day I have lost 17 lbs, which works out to about 2 lbs a week. That is not a bad result, and is on track with weight loss goals recommended by many physicians and nutrionists.

While my weight loss was acceptable, I fell far short of my workout goals. I was only able to keep on the 100Pushup plan for a week and a half. Better than nothing, but not good enough for me. I plan to get back on track as I continue my weight loss and workout throughout the spring until I reach my final goal of getting back down to my military weight (about 25 more lbs).

One aspect that I am proud of is that I stayed disciplined all month in tracking my weight loss. For me this is one of the most important parts of my regimen. Tracking my weight on a daily basis motivates me to stay on plan. Overall, I think FitFeb was beneficial and want to thank Caleb Jenkins for coordinating the program and helping to keep me motivated.

Reflecting on the FitFeb Challenge

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Sun, 01 Mar 2009 10:58:00 -0900

Now that the FitFeb challenge has wrapped up, I thought I would record some of my reflections on this past month.

DotNetNuke 5.0.1 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Wed, 25 Feb 2009 13:57:41 -0900

DotNetNuke 5.0.1 represents the latest release for the 5.x codebase. While we have made significant strides in dealing with the most significant issues discovered in the 5.0.0 release, it is still not at a level where we recommend this release for production use. DotNetNuke 4.9.2 still represents our most stable and mature release and is recommended for most users.

As always you can see a complete list with all the details of each fix/change in the ChangeLog.

Major Highlights

Added the ability to automatically update user roles without requiring the user to logout and log back in.
Changed the user deletion code to use a soft-delete rather than removing the user record. This ensures that modules like the Forums behave correctly for a previously "deleted" user.
Added IP logging to the User's table to capture the last IP address from which a user logged in.
Fixed breaking change with case sensitivity in the name of skin panes. This fix restores the case-insensitivity of previous DotNetNuke releases.
Fixed breaking change with ModuleId in DotNetNuke 5.0 which changed ModuleId to a readonly value.
Fixed breaking change in CBO.FillDictionary to restore previous behavior.
Fixed breaking change which prevented legacy skins from being installed when using the auto-install option.
Fixed breaking change which prevented updated DLLs from being replaced when repairing a module installation.
Fixed breaking change in HumanFriendlyUrls which prevented querystrings from being properly read when using HumanFriendlyUrls
Fixed breaking change in legacy modules which would not store a zip file which was not designated as a resource file.
Fixed breaking change in legacy modules which ignored zip directories. DNN 5 changed this behavior.
Fixed breaking change in default.css which resulted in changes to existing skin layouts.
Fixed issue with roles module which prevented users from delegating role administration to a non-admin user.
Fixed issue which prevented some users from logging out due to the inability of the system to detect their country.
Fixed issue with Module Action Menu which prevented it from opening links in new windows.
Fixed issue that results in an error when the Cache logs an error under the new CACHE_ERROR event type
Fixed a packaging issue with FCKEditor which caused the LinkEditor to cause an unhandled exception.
Fixed an issue which resulted in the system not being able to display the portalaliases screen

Security Fixes

Fixed version information leakage issue in the install wizard

Updated Modules/Providers

The following modules and providers have been updated in the 5.0.1 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

Forms and List 05.00.00

Providers

FckHtmlEditorProvider 2.0.3
AD Provider 05.00.01

DotNetNuke Community Edition 4.9.2 Released

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Tue, 17 Feb 2009 06:59:31 -0900

DotNetNuke 4.9.2 represents the final planned release for the 4.x codebase. The DotNetNuke 4.x platform has been in production since the launch of Visual Studio 2005 and it is finally time to shift our focus to the new DotNetNuke 5.x platform. We have a lot of great features planned for development and release in 2009, many of which have been high on the list of requested features for some time.

As always you can see a complete list with all the details of each fix/change in the ChangeLog.

Major Highlights

Added the ability to perform permanent redirect from an existing page using the page settings screen.
Fixed issue with the permanent forms authentication cookie which cause problems in SSO environments.
Fixed issue which required a workaround to import page templates into a portal
Fixed a caching issue which prevented modules from being properly cached if they used a specific caching method overload
Fixed issue which resulted in an error installing the Broadcast Polling Provider
Fixed tab redirect issue which allowed a user to directly navigate to a tab which was supposed to redirect to another URL
Fixed a continuous redirect issue which occurred when trying to upgrade from early 4.x releases to 4.9.1

Security Fixes

None

Updated Modules/Providers

The following modules and providers have been updated in the 4.9.2 packages. Please see the specific project pages for notes on what bugs or enhancements were corrected with each release.

Modules

None

Providers

FckEditor Provider 2.0.3

DotNetNuke – Coming soon to a CodePlex near you!

joe.brinkman.nospam@nospam.tag-software.net (jbrinkman) — Fri, 13 Feb 2009 01:35:00 -0900

Now that the holidays are through and we have had a chance to assess and fix a number of issues reported in DotNetNuke 4.9.1 and 5.0.0, we are just about ready to release DNN 4.9.2 and 5.0.1. To avoid some of the confusion with a dual release we are going to stagger the two releases.

DotNetNuke 4.9.2 will be released on Monday, February 16th. DotNetNuke 5.0.1 will be released the following Monday, February 23rd. Barring any major hidden show-stopping issues, DotNetNuke 4.9.2 will be the final 4.x release and all future development will focus on the 5.0 platform.

As usual we will post release notes when we make the final releases.

As part of our annual planning we have completed our roadmap for our 2009 development which we’ll be updating shortly on the DotNetNuke.com website.