Mitch Labrador's Tech Blog Less is more when you are focused.

What is BigfootMVC? BigfootMVC is an MVC style development framework developed for DotNetNuke. It’s main goal is to increase your productivity while keeping a high degree of maintainability.

This is the first in a series of posts regarding BigfootMVC. In this post I will concentrate in giving you the history as well as the goals and reasons behind BigfootMVC. In my later posts, I will focus on the technical details. Starting with how you would actually implement BigfootMVC when developing your module, and ending with a detail look at the architecture of the framework.

Last year I developed a commercial module for DotNetNuke named Tribalhut CRM. Although this was my first commercial module for DotNetNuke, I had been developing modules for DNN for a while since version 2x in fact. DotNetNuke IMHO is the best level 2 development platform for .NET. Not just because of its robust architecture, but also the huge amount of modules you can leverage when building your site… but back to the topic at hand, although I had been using the development model prescribed for DNN, it never felt natural to me for many reasons, it felt … clunky … heavy, so I endeavored to create a better way for me to build my modules. I had been using ASP.NET MVC since Preview 3 and found it to be just perfect for my development style, so i figured why not build an MVC framework for DNN.

I had four major goals as I headed into the development of this framework:

1. Everything You Need Nothing You Don’t. The framework would grow overtime as functionality was needed, no pie in the sky design.

2. Improve my productivity. This was key as I only had a limited amount of time to finish Tribalhut so I needed a framework that made it fast to develop my module.

3. Develop an end to end experience. Not just the backend code, but also a strong CSS and Javascript collection to aid in the development experience. This was key for productivity.

4. Must work with ASP.NET 2.0 and above. I wanted to support DNN version 4.6.2 and above so this was paramount. Unfortunately no LINQ goodness was available.

I spent 75% of my allotted time for Tribalhut writing the framework … as you can imagine I was starting to really get nervous at that point, but I managed to write the app using only the remaining 25% of the budgeted time. That’s when I knew I was really on to something, so I decided the right thing to do – considering I had been using DotNetNuke for a long time without paying a dime – was to open source my work so that other developers could also benefit from it.

Several months ago I told Will Strohl (twitter@willstrohl), at the time the president of the Orlando DotNetNuke User group, about my framework and my plans to open source it, so naturally he urged me to do so, I had never open sourced any of my code, so I was/am very nervous about the whole experience, so it took a little while for me to warm up to the idea but he finally together with Darrell Hardy cornered me and got me do a talk on it for our June user group meeting.

Like all developers that look at their code three weeks after writing it, I decided that it needed to be re-factored… cleaned up… and improved. So I ended up re-writing 2/3s of it for my presentation. The group members seemed to really like it which inspired me to really kick it up a notch and make it a first class development alternative for DNN. Previously my framework was a code based dependency, which means that you would drop the code into your project and it would compile within your namespace. It was written in VB as that was the language we had decided to write Tribalhut in.

There were several problems with my approach at this point that needed to be remedied:

1. It was a code based dependency, which means that it only allowed for modules to be developed in the language the framework was written in, as it needed to be dropped-in and compiled with your module.

2. It worked great for advanced module developers, but made it a little harder as a getting started alternative for DNN

3. The codebase was not well documented, worked great for me as I knew how everything worked but not so much for a new user trying to figure it out

4. There were issues with multiple modules co-existing in the same tab. It was best suited for writing modules that owned the whole tab, which was fine for Tribalhut but not so much for general purpose module development.

So after my presentation in June I decided that another re-write was needed – yes I know, again – in order to solve these issues before the framework would be ready for alpha release. So that’s what I did.

Step 1: Organize the data provider / model tier

I pulled my previously created data access framework named BigfootSQL – which I also open sourced as a result of this – into its own library project written in C#. I had two main external dependencies, one was JSON.NET, and the other was TNValidate, two open source projects. As these were open source and were also written in C#, i decided to included them in my BigfootSQL library project and namespace them under BigfootSQL in order to eliminate any conflicts with other modules that might be using a different version of JSON.NET out there, there are actually a few. They fit very well together as they both have to do with data persistence and validation, so it felt natural to package them together in the model tier. Another reason to split them into their own project, was that I use the BigfootSQL library in many other .net projects, that are not … dare I say it… DotNetNuke related so I wanted to reuse it.

Step 2: Organize my Html helpers and other web development helpers into their own library

I have a collection of helper functions that I use in all my ASP.NET projects, not just DNN development, that I wanted to reuse, so I create another library project named BigfootWeb. This library would be reusable across all asp.net development, and could also be used by BigfootMVC for DNN.

The BigfootWeb assembly also includes the Html and JavaScript helpers. These helpers I consider to be the number one productivity boost. You will see in my next detailed technical post just how productive these helpers can make you, not just for DotNetNuke development but for any asp.net develop in general.

Step 3: Organize all DotNetNuke specific code into the BigfootDNN library

This is the heart of the BigfootMVC  framework for DNN. It performs all of the route handling and activation, as well as all the mapping and execution of actions. It understands DNN and makes it extremely simple to write modules that have very advanced feature sets.

As I mentioned before, the biggest productivity enhancement, comes from the Html and JavaScript helpers, so I figured why not also make them available to users that want to write DotNetNuke modules using the traditional ASP.NET control model, rather than an MVC model. Furthermore why not have a project that mixes and matches the two as needed. This would provide for a great gradual migration story. So I did that as well.

This is why I named my library BigfootDNN rather than BigfootMVC, that is because you can do any type of DNN development not just MVC following a simple set of patterns in your module. This option gives you access to the huge productivity enhancements that can come from writing a web 2.0 application using the Html and JavaScript helpers.

Step 4: Create a solid Javascript framework

Let me just say this… I don’t love JavaScript, but I can’t seem to get away from it, so might as well make it easy to work with. I use the following plugins to simplify my JavaScript existence: jQuery, jQuery.Form, jQuery.Validate, and REQ.

REQ is the main loader and it handles the proper checking and loading of all javascript dependencies by using the dependency map. It won’t load jQuery if it is already loaded, same for all the other plugins. This ensures that if there are multiple BigfootMVC modules on the page, the references will be loaded only once.

If you are using the MVC model, then you don’t have to do anything, all these dependencies are automatically properly referenced for you. If you are using the classic DNN model then you just need to add this single line to the top of your control.

<%=DnnApp.AddBigfootScriptAndCssDependencies()%>

Step 5: Create a resistant CSS framework

I highlight resistant as this seems to be one of the more frustrating aspects of creating a commercial module since you can’t predict what the skin will look like, or if the skin will work properly. Bottom line is that you need your module to look consistently good even on crappy skins.

The second aspect of being a good DNN module citizen is making sure that your CSS does not bleed out into the skin. This is extremely important as you don’t want your module CSS to screw up anything that gets loaded after your module.

The CSS stylesheet in BigfootMVC has a module level reset, as well as class selectors than when utilized will ensure that these styles take precedence. Styles are module specific which means that it won’t bleed out into other modules in the site.

It includes common alignment, proper floating for IE6+ , common sizing for the basics of  a grid system, the reset is based on Eric Meyer’s reset, proper typing, margin, and font size presets as well as many other all purpose utility classes you can use, like text alignment, etc.

Step 6: Create a project template that makes it dead simple to get started

I’m working on this and should be ready soon.

Summary

This redesign enables a more reusable codebase that can be used to support not just DNN development but any other type of ASP.NET development. BigfootMVC will make it extremely simple to create new applications by simply referencing three DLLs in your DNN project. I’ll show you how to this in my next blog post.

You can browse the source code here http://bigfoot.codeplex.com

There is a bug in the jQuery validate plugin when running in internet explorer. When the validate function is called and errors are found, the invalid label error does not show, or rather it shows, it is just empty.

After considerable digging around  I found the culprit. jquery.Validate uses the function defaultMessage to determine which error message to display, it in turn calls the findDefined function to determine which of the parameters is defined and it uses that one as the message.

The bug is in findDefined function, it uses this line to determine weather to use that message or move to next one:

if (arguments[i] !== undefined) {

in internet explorer this comparison is incorrect. The correct comparison to get the desired behavior would be

if (arguments[i] != undefined) {

I’ve tested this last line in all the major browsers and it works great. Hopefully this will save you some time when debugging this particular problem.

Here is the fixed function:

findDefined: function() {

for (var i = 0; i < arguments.length; i++) {

if (arguments[i] != undefined) {

return arguments[i];

}

This week I found a peculiar problem while trying to do validation inside a jQuery UI dialog box. Validation, although properly configured, would not happen, it would always show as valid.

This is the form, it is using the jquery.validation and the  jquery.ui.dialog components.

   1:  <form id="form1" runat="server">

   2:      <div id="dialog"></div>

   3:      <input type="button" id="load" value="Load Form" />

   4:  </form>

   5:  

   6:  <script type="text/javascript">

   7:  

   8:      $(function() {

   9:  

  10:          $('#form1').validate();

  11:  

  12:          $('#load').click(function() {

  13:              $.get('_form.aspx', function(data) {

  14:                  $('#dialog').html(data);

  15:                  $('#dialog').dialog();

  17:              });

  18:          });

  19:  

  20:      });

  21:  

  22:  

  23:  </script>

as you can see it is doing an ajax request to load the form. It then brings up the dialog box. Notice that the dialog div is inside the form therefore I’m expecting the loaded page to render within the form tag of the current page. This is the form that is loaded:

<input type="text" id="subject" class="required" />

<input type="submit" value="Submit Form" />

The problem is that the UI dialog will add a wrapper div and place it outside the form tag. It then moves the dialog div to be within it, effectively moving it outside the form. Therefore validation does not work as it is outside the form tag.

To fix this we write this simple line of code to reverse the process and move the dialog wrapper to be within the form tag.

$('#dialog').parent().appendTo($('#form1'));

It took me a little while to figure this out, and hopefully this will save you some time.

Cheers!

I would like to wish all the fathers out there a very happy father’s day.

Mother’s day is the biggest rose selling day of the year, I wonder what is the biggest selling item for father’s day? Maybe tools, a new grill, etc. You see the pattern, we only get things to work harder! What’s up with that?

I imagine the geek Dad’s biggest selling category is tech, perhaps the new iPhone 3Gs, hint… hint…

Happy Father’s Day to all of us!