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

Let’s analize html 5 which seems to be the altermative apple is putting forward. It is an unfinished standard!!!! Not only that but it is not being implemented across browsers the same way. Firefox supports only the ogg video format on the video element. Everybody else does h.264, and older browsers dont have support for html 5 period. On top of that, the world’s largest browser (ie) does not currently support html5. So if you wanted to provide a video experience for the users of your site you would have to encode your video as ogg and h.264. You would then also need to fallback to flash for the majority of your users.

So going back to the original question, will apple be hurt by their decision….. in my opinion, NO.

We the web developers are the ones really hurt by this. Apple and Adobe can afford to live in the clouds but us web devs that are here in the trenches still need to create sites that can operate in the real world.

This one happens when using the $.format function which is part of jquery.validate 1.7 and previous versions too.

When you use the $.format like this:

$.format(“Hello {0} ”, userName)

if the userName variable is null then this will be the outcome: “Hello null”

To fix this issue you can add this simple line to the $.format function to make sure the value is not null before merging it with your string.

This:
$.each(params, function(i, n) {
source = source.replace(new RegExp(“\\{” + i + “\\}”, “g”), n);
});

Becomes this:
$.each(params, function(i, n) {
if (n == null) n = ”;
source = source.replace(new RegExp(“\\{” + i + “\\}”, “g”), n);
});

See the video bellow for the bug and fix in action.

http://www.screencast.com/t/MGZlNjAxMDkt

Hope this helps!
Mitch

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];

}

I haven’t presented in a while and I have to admit I was a bit nervous, and to make matters worse the projector was not wanting to cooperate with me. Suddenly the room got really hot and I started sweating… I’m sure my sweating had nothing to do with the silence in the room while people waited for the technical problem to be resolved

It turned out that when I closed my machine at the office, it was connected to multiple monitors, so when I hibernated it remembered those settings and I could only get to projector to work as an extension of my desktop, like a second monitor.

Anyways… great learning opportunity, and I can’t wait to try it again. On to the technical stuff…

Goal:

I want the JavaScript file references in my pages to load the debug version of the JavaScript files when my visual studio solution is in debug mode. When Visual Studio is in release mode, I want a single compressed JavaScript file to be loaded.

Solution: (download)

Step 1: Download jsmin.exe from http://www.crockford.com/javascript/jsmin.html

Add it to your scripts directly in your project. You should not deploy this with your project, it is only needed during compile time to minimize and combine your JS files.

I use the following structure to store my javascript files:

Step 2: Add a post build command

Right click on your project, click properties. Select the compile tab and click on the build events on the bottom right of the screen.

Enter the following command in the post-build event command line field:

 type “$(ProjectDir)content\js\libraries\*.debug.js” | “$(ProjectDir)content\js\libraries\jsmin” > “$(ProjectDir)content\js\libraries.min.js” 

This command does two things. First it looks for all the javascript files in your “content/js/libararies” directory ending with .debug.js and pipes it into the jsmin executable as one long string. Second it tells jsmin to output the compressed and combined JavaScript code to a single file content/js/libraries.min.js

Step 3: Add a debug flag

We need a way to figure out if we are in debug mode or release mode so to do this we are going to add a shared function to a helper library that will return true if in debug mode, and false if in release mode. In this function we use a compiler statement to compile “return true” when in debug mode and “return false” otherwise.

Public Shared Function IsInDebugMode() As Boolean
#If DEBUG Then
        Return True
#Else
        Return False
#End If
End Function

Step 4: Add a conditional statement to your pages

To your page you simply add this:

<% If jsmin.Helpers.IsInDebugMode Then%>
    <script src=”content/js/libraries/01-jquery-1.3.2.debug-vsdoc2.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/01-jquery-1.3.2.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/02-jquery-ui-1.7.2.custom.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/03-jquery.autocomplete.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/04-jquery.blockUI.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/05-jquery.cluetip.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/06-jquery.form.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/07-jquery.validate.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/08-jquery.values.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/09-json2.debug.js” type=”text/javascript”></script>
    <script src=”content/js/libraries/10-app.debug.js” type=”text/javascript”></script>
<% Else%>
    <script src=”content/js/libraries.min.js” type=”text/javascript”></script>
<% End If%>

This tells your page that when IsInDebugMode is true, reference all the debug scripts, otherwise reference only the libraries.min.js script

Making it better

This is great, but I dislike having to add these conditional statements to every page, so created another simple helper function that goes through my libraries directory, grabs all my debug files and creates the html string to be included in the page. following the same rules, if in debug mode all the scripts, if in release mode only libraries.min.js

Public Shared Function JSReferences() As String
    Dim key = “JSReferences”
    Dim context = HttpContext.Current

    If context.Application(key) = “” Then
        If IsInDebugMode() Then
            Dim data = New StringBuilder
            For Each f In Directory.GetFiles(context.Request.MapPath(“~/content/js/libraries/”))
                f = f.ToLowerInvariant
                If Path.GetExtension(f).ToLowerInvariant = “.js” AndAlso _
                        f.EndsWith(“vsdoc2.js”) = False AndAlso _
                        f.EndsWith(“vsdoc.js”) = False Then
                    data.AppendLine(String.Format(“<script src=’{0}’ type=’text/javascript’></script>”, “content/js/libraries/” & Path.GetFileName(f)))
                End If
            Next
            context.Application.Add(key, data.ToString)
        Else

            context.Application.Add(key, “<script src=’content/js/libraries.min.js’ type=’text/javascript’></script>”)
        End If
    End If

    Return context.Application(key)
End Function

now I can replace the code in my html pages with this single line statement.

<%=jsmin.Helpers.JSReferences%>

That’s it. Enjoy!

Thanks to Dave Ward for the original idea http://encosia.com/2009/05/20/automatically-minify-and-combine-javascript-in-visual-studio/

Here is a dead simple way to fix it.

1. First find the offending library that is messing with your jQuery IntelliSense. Do this by commenting one at a time and pressing Ctrl + Shift + J to force the JS IntelliSense engine to regen. Repeat until you don’t get a JS IntelliSense error (it should come up in the status bar, and as a warning in the errors window)

2. Replace the offending javascript file with something like this.

<script src=’<%= “../../Scripts/your_javascript_file.js” %>’ type=”text/javascript”>

When you do this, the Visual Studio JS intellisense engine, does not try to process  the javascript file, and you get your jQuery IntelliSense back.

Hope this helps. Cheers!

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!

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!

I’m back to C# though and this time is going to be an MVC project. So whenever I’ve been away from a technology for a few months, I pickup my favorite book on it and go over the basics. I have to say that I’ve missed the style of C#, even though I’ve enjoyed the xml literals in VB…sigh…

So C# 3.0 In A Nutshell it is, what a great book. It covers C# from the basics to the common usage scenrios accross the different technologies (asp.net, LINQ, etc…) .

I’ve also started to create a new MVC template so I’m putting together all the usual suspects that will make my development life easier.

1. jQuery plugins and other useful JS libraries

• Validation Plugin
• jquery.values
• BlockUI
• jQuery.UI
• json2.js
• jquery.form

2. JavaScript minify and combine. I then use jsmin to setup my automatic JS minify and combine through a VS post built event. Here is a great blog post from David Ward, who gets credit for the original idea.

3. Replace the existing template for this nice free CSS template from opendesign.org and we are half way there to creating a kick butt template.

I still have to setup xVal and a few other things, but that will be for the next post. For now, I’m ready to get started.