From: http://stackoverflow.com/questions/833997/end-date-greater-than-start-date-jquery-validation

jQuery.validator.addMethod("greaterThan", function (value, element, params) {
 
            if (!/Invalid|NaN/.test(new Date(value))) {
                return new Date(value) > new Date($(params).val());
            }
            return isNaN(value) && isNaN($(params).val()) || (parseFloat(value) > parseFloat($(params).val()));
        }, 'Must be greater than {0}.');

First let me say that I’m a pragmatist at heart, and I write software for a living, so I must find a balance between perfection, maintainability, and profitability.

I’m sure there are other people out there that have created their own development style that works very well for them, for me however, after using most of the shiny three letter patterns, I have found that these principles give me the best of both worlds, RAD development and a Maintainable application. And best of all they help me enjoy my job.

1. Hand Crafted Model

I use POCO objects as my model. These objects are hand crafted by me instead of being generated by a tool, and they are the foundation of my app.

2. No ORM

I do not use an ORM, but rather I use my own tool BigfootSQL. It gives me the best of worlds, complete control over my SQL while at the same time saving me from all the grunt work of object Hydration and query execution. I have been developing software for a while, and have fallen victim to the Microsoft fascination with changing data access technologies with almost every release. My strategy is to try to stay as close to SQL as possible while minimizing the manual work, BigfootSQL does this for me.

3. Operation based validation

I validate at the point of the operation execution, rather than performing model based validation. When validation must be shared across operations then a validation helper is employed in order to share this logic. Models rarely if ever are validated in a vacuum, validation changes depending on the type of operation being performed and depending on more than a single model object. Operation validation on the other hand, validates at the operation end, it simply looks at what the action itself is, and validates the action. This way you can effectively and simply validate against multiple types of operations against your object model while keeping your validation and business rules simple. It also keeps you from writing validation code that you won’t use. To achieve this, I use a modified version of TNValidate. TNValidate is an open source fluid interface style validation framework that makes validating my objects extremely simple. I’ve repackaged my modified version of TNValidate into BigfootSQL. I also use a set of Post helper methods that help me retrieve the values from a post while providing simple type validation and required validation. You can find my PostHelper class in my open source project BigfootMVC, this is an ongoing compilation of helper methods I use for MVC style development. I use these helpers when developing for classic ASP.NET, ASP.NET MVC, and DotNetNuke module applications.

4. Highly specific and smart ViewModel

For every view, I create a ViewModel whose job it is to handle all data requirements and operations for the view. These VMs are smart and self aware, they have static factory methods for creating themselves, and also handle all view operations which get executed by the Controller. They talk to the Repository to get data and execute operations against the Database. They help me keep my controllers thin by delegating a lot of the operations responsibility closer to where the action is.

5. No IoC container

It is ok to take a dependency on your own code. Most of of the time we find ourselves using IoC simply for the reason of making our code testable. Instead of adding complexity to the code to make it testable, I use a smart mocking framework that allows me to effectively mock any kind of dependency without having to use the IoC pattern, I use JustMock by Telerik. This allows me to write my applications in a much simpler way while still keeping them completely testable. I know this is a religious topic for a lot of people, however in my experience, after using several IoC containers, you are simply adding undue complexity to 90% of your apps. I do acknowledge there is a 10% that need it, all I’m saying is, use it where required, be a craftsman, use the right tool for the right job.

6. Highly Helped Views

I have developed a set of Html helpers that allow me to perform most view operations, including complex ajax operations, in a very simple way. They help me be extremely productive while creating highly responsive web interfaces. As a developer of some experience with web development, highly responsive (ajax) web interfaces and productivity do not always go hand in hand. I set out to develop a rich set of helpers that allow me to perform the 80% case scenarios with one line or less of strongly typed code. I open sourced all of these helpers under my ongoing BigfootMVC project.

7. Take a dependency on JavaScript

For web applications, I take a dependency on JavaScript. This allows me to deal with older less capable browsers much more efficiently. While not all sites can do this, most applications are safe to take a dependency on JavaScript. I also use a strong master page that helps me deal with the browser differences. I use jQuery, Selectivizr, and a few other tricks to make working with IE6 and other non CSS3 HTML5 browsers much easier and less painful.

8. Strong CSS reset with a rich set of helper classes

I have published the CSS framework that I use, BigfootCSS, it is a compilation of best practices I have found around the web published by really smart people like Eric Meyer, Paul Irish, and a few others. I have also loaded it with a lot of helper classes that I use over and over again in more utilitarian application interfaces. For me it provides a good middle ground between inline styles and 100% custom CSS. I reserve the use of custom CSS classes in my design for what is truly custom, and use helper classes for the common operations.

Summary

If I had to sum up my strategy in one word – or one acronym rather – I would say “KISS”. Above all keep it simple, that is the secret to productivity and maintainability.

So that’s it really, a few simple no non-sense principles that make my life easier when it comes to developing web applications.

Hope this helps!

Mitch

Goals:

1. Detect whether jQuery is installed

2. Determine whether the right version of jQuery is installed. I will use 1.4.2 as my base.

3. Make sure to not cause conflict with other libraries that might be using the $ variable

Code:

<script type=”text/javascript”>

    // Check whether jquery 1.4.2 or greater is loaded
    var loadJQuery = (typeof (jQuery) == 'undefined' || 
                jQuery().jquery < "1.4.2");

    // Add a marker to invoke no conflict when the $ 
    //    is mapped to a library other than jQuery
    var callNoConflict = (typeof ($) != 'undefined' 
                && typeof (jQuery) == 'undefined')

    if (loadJQuery) {

        var filename= ‘your path to the jquery file’;
        var fileref=document.createElement('script');
        fileref.setAttribute("type","text/javascript");
        fileref.setAttribute("src", filename);
        document.getElementsByTagName("head")[0].appendChild(fileref);

    }

    if (callNoConflict) {
        jQuery(function(){
            jQuery.noConflict();
        });
    }

</script>

Will Strohl has put together a great article on the best practices for using jQuery within DNN

Right, so the the topic of this post. Whenever an element being validated by jQuery.Validate in your page is found to be invalid, jQuery.validate  – referred to as “VAL” from now on – adds a label element next to it showing the error message for the particular validation being performed. This is fine for most situations, however sometimes you need to handle scenarios where the default placement of the error message is not quite right. The creators of VAL anticipated this and provided several built-in ways to customize this behavior with just a little bit of effort. These are the three scenarios I find myself using most often:

Scenario 1: I want to show all my error messages inside a single error container as a UL element

                   $("#addEventForm").validate({
                            errorContainer: "#errorContainer",
                            errorLabelContainer: "#errorContainer",
                            errorElement: "li”

                     })

errorContainer : is a space separated list of element ids that will be shown when the form is invalid and hidden when the form is valid.

errorLabelContainer : this is the id (or any jquery selector string) of the element that will contain the error labels generated for each invalid field

errorElement : by default the error element generated by VAL is a label control. If your container is a UL then you can set this variable to “li” in order to generate LI elements instead of label elements.

Scenario 2: I want to show the error control before the field it is validating rather than after it (which is the default location)

                    $("#addEventForm").validate({
                            errorPlacement: function (error, element) {
                                error.insertBefore(element);   
                             }          
                        })

errorPlacement: is the function that is called by VAL to inject the error element into the DOM. By overriding this function we are able to place it anywhere we want. Both the error and element parameters passed into the function are jQuery objects. Sky is the limit as to what you can do here.

Scenario 3: I have a form with two input fields, first name and last name. They are located next to each other, and they are both required. When either one of these fields is empty I want to show the error label generated by VAL inside a div element named “nameError” which is placed bellow the two input controls.

To do this we are going to use the same trick as in scenario 2 except that we are going to inspect the name of the invalid element being passed into the errorPlacement function and do a custom injection of the error message for just the first and last name. For all other errors we do the default, which is append the error label next to the invalid input control.

                    ("#addEventForm").validate({
                            errorPlacement: function (error, element) {
                                     if (element.attr(“name”) == “fname” || element.attr(“name”) == “lname”)
                                            $(“#nameError”).append(error);
                                     else
                                             error.insertAfter(element);
                             }          
                        })

That’s it!

Enjoy!

This is the workflow I want to use when editing this static html content to be included in my portal:

1. Open my favorite html editor

2. Create a new html file and write some cool / mean / clean html code

3. Reference some special css and js files if I want to

4. Upload it to my site

5. Add the html direct module, point it to the file and that’s it.

Editing is now simply opening the html file, editing it and republishing it. Rinse and repeat

Overview:

1. Create a new module through the DNN interface

2. Edit the View.ascx file that gets created automatically, to render the file named in the module settings

3. Create an editor to edit the fileName module setting. This must be done in the same page. So I’ll show it when the module is editable, and hide it when it is not.

Here is a video that shows the process, and you can download the source packaged module bellow.

Code:

   1: <%@ Control Language="C#" Inherits="DotNetNuke.Entities.Modules.PortalModuleBase" %>

   2: <%@ Import Namespace="System.IO" %>

   3: <%@ Import Namespace="DotNetNuke.Entities.Modules" %>

   4:  

   5: <script runat="server">

   6:     

   7:     protected void Page_Load(object sender, EventArgs e)

   8:     {

   9:         // Render the file

  10:         RenderFile((string)Settings["fileName"]);

  11:         

  12:         // Show the editor

  13:         if (IsEditable && !IsPostBack)

  14:         {

  15:             fileNameDiv.Visible = true;

  16:             fileName.Text = (string)Settings["fileName"];

  17:         }

  18:     }

  19:  

  20:     // Render the html file

  21:     private void RenderFile(string renderFileName)

  22:     {

  23:         try 

  24:         {

  25:             if (!string.IsNullOrEmpty(renderFileName))

  26:             {

  27:                 // Strip off the initial slash if any

  28:                 if (renderFileName.StartsWith("/") || renderFileName.StartsWith("\\")) 

  29:                     renderFileName = renderFileName.Substring(1);

  30:                 

  31:                 // convert into a physical path

  32:                 renderFileName = "~/portals/" + PortalId + "/" + renderFileName;

  33:                 

  34:                 // render the text of the file

  35:                 fileContent.Text = File.OpenText(Server.MapPath(renderFileName)).ReadToEnd();

  36:             }

  37:         }

  38:         catch (Exception ex)

  39:         {

  40:             fileContent.Text = (IsEditable) ? ex.ToString() : "Error displaying module content. Unable to find file!";

  41:         }

  42:     }

  43:  

  44:  

  45:     // This changes the rendered file to a new file and saves in the module settings

  46:     private void SaveFileNameButton_Click(object sender, EventArgs e)

  47:     {

  48:         ModuleController objModules = new ModuleController();

  49:         objModules.UpdateTabModuleSetting(TabModuleId, "fileName", fileName.Text);

  50:         RenderFile(fileName.Text);

  51:     }

  52:     

  53: </script>

  54:  

  55:  

  56: <%--Edit the file name--%>

  57: <div runat="server" id="fileNameDiv" visible="false">

  58:     File Name <br /> 

  59:     (i.e. HomePageFiles/Content.htm where "HomePageFiles" is a folder at the root of the portal): <br />

  60:     <asp:TextBox runat="server" ID="fileName" width="100%"></asp:TextBox> <br />

  61:     <asp:Button runat="server" ID="saveFileNameButton" Text="Save File" OnClick="SaveFileNameButton_Click" /> <br />

  62:     <br /><br /> 

  63: </div>

  64:  

  65:  

  66: <%--Placeholder for the html content--%>

  67: <asp:Literal runat="server" ID="fileContent"></asp:Literal>

  68:  

  69:  

You can download the packaged module here

http://cdn.mitmar.com/HtmlDirect_01.00.00_Install.zip

Rather than just complaining about it, I figured I would do a bit of constructive criticism. We are going to look at the blog post page. I got there by clicking a link on Twitter by Joe Brinkman. My main objective is to read the blog post and move on.

Use Case: Read the blog post

1. First I’m overwhelmed by everything going on in the page. The actual content of the blog post – higlighted in green – is deemphasized to the point that I have to hunt for it. Let’s not forget that the post is the reason I’m here, it is the main point of the page.
2. One third of the page fold is taken up by irrelevant data to the use case. The header menu must be deemphasized. It should not take 1/3rd of the page fold.
3. The left pane content should be completely removed. I came to the page to read the blog post, I don’t need to search for it, or care about the blog roll, this would be great for the landing page of the blogs section but not here. This page should be all about reading the post content.
4. Yes, I know it is a blog post that’s why I’m here is there a particular reason why "DNN Blog" must me more prominent than the actual blog post title?
5. The actual post content font, again the main point of the page, is small and does not have enough line height to make it easy to read.

Result: Joe’s *great* post has been relegated to the last position of visual importance in the page.

Here are a few sites that get it right:

In everyone of these instances the most important emphasis in the design is given to the content, as it should be, everything else is noise. Notice how they all have other things going on in the page, but nothing takes precedence over the post content.

The chrome is not as important as the content!

 

BigfootCSS is a 22k uncompressed / 6k compressed CSS stylesheet that can be used to aid you in the styling of your web pages. It is a collection of real world CSS classes, box model fixes, generic classes for various common styles, standard Ad sizes, and a solid browser reset based on Eric Meyer’s CSS reset. It can be applied to the whole page, or it can simply be applied to a particular element within the page and its children. This latter option is very useful for CMS module development as it makes it easy to style just your module without being affected by or affecting the host page.

If you have written a module that sits inside of DotNetNuke, WordPress, Jumla, etc. you know what I mean. You can’t control the skin in which your module runs, but you have to provide a reasonable amount of protection to ensure the proper layout of your module. You must also be a good citizen of the ecosystem and not allow your styles to bleed into the rest of the skin. BigfootCSS solves this problem very easily by only targeting elements with a certain id.

Why?

Over the years I have used a number of CSS frameworks. In them I found a lot of good techniques, and others… well not so great. So I started creating my own CSS bag of tricks, I’m not sure I would call it a framework, but rather a collection of real world CSS classes, hacks, and fixes. Most of the tools in this toolbox come from everything I’ve liked about the other frameworks I’ve used, most of the credit goes the guys that have figure out the different hacks to fix the IE box model, to create a proper reset, etc. I’ve lovingly named this compilation of ideas bigfootCSS.

Context in which I use bigfootCSS:

1. I’m a developer creating business apps, not just websites. A lot of the utility classes found in the framework – for lack of a better word – are meant to aid in the utilitarian way in which business applications are styled.

2. I dislike inline styles, but do not mind a composition of classes to achieve a certain result. This is a good middle ground between a completely custom rule for the element and inline styles.

3. I reserve the creation of custom styles for the elements that truly are unique in your project. For example I don’t like to reinvent the wheel when doing grid layouts. I have a solid grid system that is tested across browsers.

4. I’ve said this before, but it bears repeating I’m a developer, not a designer.  This is a framework that has worked for me in my projects. It is not 100% perfect or bug free. For the 10% outlier, I simply write custom CSS to cover these use cases.

What’s in it?

A browser reset

I believe Eric Meyer’s is the best and longest standing browser reset out there. For you who are not familiar with browser resets, the short of it is, that every browser before they apply your styles, the browser’s default stylesheet gets applied, and it creates the base set of styles for the the page. Trouble is, every browser has a slightly different base style, which makes your design vary from browser to browser based on the inherited base style. To counter this, you can create a reset if you will, which neutralizes all default browser styling and creates a baseline which is the same across all your browsers.

Baseline

Once you have run a browser reset, you have created a consistent baseline accross all browsers by removing all (almost) styles, but now you don’t have any defaults. The baseline serves the purpose of creating a default look for the common elements like heading tags, paragraphs, etc.

Fix for IE box model. The clearfix hack

The clearfix hack is used in order to clear floated elements. While this should be a straightforward procedure, IE makes it very challenging, as is with most other issues in IE, it implements the html spec slightly different from other browsers. The included clearfix hack, fixes all these inconsistencies and renders correctly across IE5.5+ as well as Firefox, Chrome, Safari, Opera. See this article for a clear description of the problem and it’s solutions.

The short of it is, if you have this markup, if you are floating elements inside a container, all you have to do is apply the clearfix class to the parent container and all floated children will behave correctly. for example:

   1: <div class="clearfix">

   2:     <div class="fl">fl = Float left</div>

   3:     <div class="fr">fr = Float right</div>

   4: </div>

Type

As part of the baseline, it creates a base type setting which is as follows:

   1: {

   2:     font-family:Segoe UI,Arial,Verdana,Helvetica,sans-serif;

   3:     font-size: 12px;

   4:     text-align:left;

   5: }

This works well in most browsers, and while I understand the shortcomings of pixel based font sizes, it just works, like I’ve said before for the cases where this does not fit, then use a custom classes, or change the default.

There is also standard sizes represented by classes. Theses classes correctly fix the problem of being overridden by element direct styling typical in a, input, td, select, and textarea tags. When you assign one of these classes to any element, it insures that it takes precedence.

s = small (13px)

xs = extra small (10px)

xxs = extra extra small (9px)

m = medium (16px)

l = large (19px)

xl =extra large (24px)

xxl = extra extra large (32px)

Floats

To float elements left or right simply apply these classes to the element. Remember to wrap them with a container that has the clearfix class applied as in the example above.

fl = float left

fr = float right

Widths, Heights, Padding and Margins

I know that some of you will balk at the idea of classes with preset sizes, but before you decide to start hurling stones, remember what I said before, every class that is there, is there because I use it often and find it to simplify and speed up my development. Like I’ve said this is a good middle ground before custom css rules for everything, and inline styles (which are evil).

w{number} = Sets the width of the element to the {number} of pixels specified. for example w25, sets the width of the element to 25px.  Numbers from 1-10 are in 1 pixel increments, 10-200 are in 5 pixel increments and 200-600 are in 25 pixel increments and 600-980 are in 10 pixel increments. With the exception of the standard ad sizes as found here

wp{number} = Sets the width of the element in percentages of it’s parent’s size. 1-10 and 95-100 are in 1% increments, the reset are in 5% point increments.

h{number} = Sets the height of the element in pixels. Numbers from 1-31 are in 1 pixel increments, from 30-250 are in 5 pixel increments, 250-600 are in 10 pixel increments

m{number} = Sets the margin for an element to the specified number. Numbers from 1-10 are in 1 pixel increments, 10-50 are in 5 pixel increments.

mt{number} , mr{number}, mb{number}, ml{number} = Sets the margin-[top, right, bottom, left] correspondingly. Numbers from 1-10 are in 1 pixel increments, 10-50 are in 5 pixel increments.

p{number} = Sets the padding for an element to the specified number. Numbers from 1-10 are in 1 pixel increments, 10-50 are in 5 pixel increments.

pt{number} , pr{number}, pb{number}, pl{number} = Sets the padding-[top, right, bottom, left] correspondingly. Numbers from 1-10 are in 1 pixel increments, 10-50 are in 5 pixel increments.

Colors and Backgrounds

These are particularly useful in application development, as you often want to change the color or background to a preset set of colors, but it is not imperative that you be extremely precise with the color as you would with the palette of a hand crafted site. In these cases having some preset colors greatly improves the consistency and speed with which you can achieve relevance through design in your applications.

bg{color} = stands for background-color and then the color specified. colors included are: white, black, light, dark, hl (which means highlight, sets the background to a light yellow), the colors are as described by their name.

black, white, red, xdard, dark, light, xlight = Sets the color css attribute of elements (including overriding the anchor tag color if applied to an anchor) to the appropriate color.

Display and Position

hide = sets the display property of the element to none

block = sets the display property of the element to block

inline = sets the display property of the element to inline

inlineb = sets the display property of the element to inline-block

prel = sets the position to relative

pabs = sets the position to absolute

pfixed = sets the position to fixed

pstatic = sets the position to static

Text alignment

tr = text-align: right

tl = text-align: left

tc = text-align: center

tj = text-align: justify

tvt = vertical-align: top

tvc = vertical-align: middle

tvb = vertical-align: bottom

Grid

The grid is loosely based on the 960 fluid grid. It basically implements a 16 column grid that uses percentages. I use percentages because it is particularly useful to include in other containers that might not be necessarily the whole page. For instance you can apply the grid to just a div element within your page, and it will divide that element into 16 equal columns using percentages. Particularly useful when using the the system for styling a module.

Best to way to show it is to show you some code:

   1: <!--You apply the grid to an element by adding the g16 class to it-->

   2: <div class="g16">

   3:     <div class="gc5 firstc">

   4:         This takes 5 of the sixteen columns and marks it as the first column with the firstc class,

   5:         the firstc class kills the left gutter space for this column

   6:     </div>

   7:     <div class="gc3">

   8:         Yet another column taking another 3/16 of the space

   9:     </div>

  10:     <div class="gc8 lastc">

  11:         Another column taking the ramining 8/16 space in the grid.

  12:         lastc class marks the column as the last in the grid and kills the right gutter

  13:     </div>

  14: 

  15: 

  16:     <!-- This clears the previous columns, but you only have to

  17:          use when the next column is not a full column -->

  18:     <div class="clear"></div>

  19: 

  20:     <div class="gc16">

  21:         A full column does not have to be cleared or marked with the lastc and firstc classes

  22:     </div>

  23: 

  24: </div>

The grid is pretty simple really, just a way to evenly divide any container element into 16 equal columns.

Miscellaneous Classes

pointer = sets the cursor to be the pointer when the mouse is over this element

cnomal = sets the mouse cursor to the normal sate

b = set the font-weight to bold

fieldlabel = sets an element ot display lock and ad bottom padding of 3 pixels this is used on <label> elements that pertain to input controls

nowrap =adds text-whitespace: nowrap

strike = adds text-decoration: line-through

cmd = used on anchor tag to make them small red and bold as it it were a command rather than just a simple link. { font-size: 10px; font-weight:bold; color:red; }

hlist = makes an unordered list’s <ul> elements display inline and horizotally, useful when creating menu and other horizontal use of <ul>

tablemin = turns a properly formatted table (one that uses the <thead> <th> and <tbody> elements) into an instance nicely displayed one by adding formatting to it in a very simplistic style

error = When applied to an element it turns it’s color red, and sets the font and font size to display as an error. Useful in applications when you want to visibly adorn an invalid input.

What about partial page styling (CMS mode)

I also created an alternative CSS stylesheet, BigfootWeb_Module.css, which would be referenced instead of BigfootWeb.css. It contains all of the same classes and styles, except they are only applied to the element in your page named bfbox.

Also by default the browser reset is not applied unless you specifically also add the reset class to the bfbox element. That’s it, very simply really. A quick example:

   1: <div>

   2:     This some other page content, not affected by bigfootCSS.

   3:     bigfootCSS rules do not apply here.

   4: </div>

   5: 

   6: <div id="bfbox" class="reset">

   7:     All elements inside this box are now under the bigfootCSS reset, and baseline

   8:     as well as all css classes and rules would apply to all children of this element

   9: </div>

  10: 

  11: <div>

  12:     Back to the page, again not affected by bigfootCSS.

  13: </div>

Please not that if you don’t want the browser reset portion to apply to your bfbox container, simply don’t apply the reset class. This will allow you to inherit all the CSS rules from your skin / page while still being able to take advantage of most of the classes in the framework.

Putting it all together

You can now put these classes together to create a very fast and clean layout for your page without having to create custom CSS rules for everything.

For a more complete example please visit http://cdn.mitmar.com/bigfootcss/Main.html

Cheers!

Mitch

This is workflow I want to use when editing these static html content to be included in my portal:

1. Open my favorite html editor

2. Create a new html file and write some cool / mean / clean html code

3. Reference some special css and js files if I want to

4. Upload it to my site

5. Add the html direct module, point it to the file and that’s it.

Editing is now simply opening the html file, editing it and republishing it. Rinse and repeat.

You are probably wondering why not just create a simple html / or asp.net website?

The answer is that I want to take advantage of many of the DotNetNuke modules out there, but I still want to edit my static content pages easily and without the delay of having to open up the page, login, open the page, select edit on the html module, pasting the html code, and hit save.

Convention over configuration

I don’t want to have any options on the module other than the relative location to the file without having to specify the extension so for home/content.html i just want to refer to it as home/content in my module. Convention to follow:

1. Every portal root folder will have a folder in it called ~/Portals/[PortalId]/HtmlDirectFiles.

2. HtmlDirectFiles Structure:

               HtmlDirectFiles
                     – images
                     – css
                      – js
                      – file.html | foldername/file.html

3. Files must be named with the extension .html

4. Html file will reference images, css, and js files relative to its location. When you upload your html file, also upload your images, css, and any js files to corresponding folder under HtmlDirectFiles folder.

5. Html file will not include the html, head, or body tags

6. DotNetNuke caching rules will be followed

Of course content editors will have to be smart about referencing css and js files taking into account the implications of including the files multiple times on the page, etc. I assume we are all pros here and you know that you are doing and how to avoid this.

That’s it, pretty simple really, but should make my life a lot easier. Stay tuned for a release date.

Cheers!

This is part one of the notes I’ve taken as I went through the book. This is something I usually do when learning a new language, and I use it as sort of cheat sheet.

DISCLAIMER: These are the notes of a .NET Developer learning the Ruby language. These are the concepts as I understand them coming from a .NET background, and may not necessarily be correct.

STRINGS:

‘Hello, darling’ –> single quotes can only contain simple strings (no transformation)

"hello, darling \n \r" –> double quoted offer more escape sequences

"inches/yard: #{12*3}" –> inches/yard: 36

"#{"Tora! "*3}"     –> Tora! Tora! Tora! . You can embed string definitions within other strings

NUMBERS:
-123456789     –> -123456789 # Fixnum

0d123456789     –> 1234567890 # Fixnum

1234323424231 –> 1234323424231    # Bignum

0x5C1     –> 1473     # Hex

01411     –> 777     # Octal

1_90_33     –> 19033     # Fixnum

-4.abs     –> 4

6.zero?     –> false

COLLECTIONS:
    RANGE: Ranges hold a sequential collection of values, such as all numbers between 1 and 9 or the letters from A to Z. A range is created by placing a series of dots between the lower and upper limit
        48..81 –> 48 to 81

        48…81 –> 48 to 80

        range === 49 –> true

        range.include? 49 –> true

   ARRAYS:
        its_so_empty = []

        oh_so_empty = Array.new

        hello = ['ni hao', 'bonjour', 'hi', 'howdy']

        random_types = [13, 'napkin', (1336 + 1).to_s]

        %W (one two three) –> ["one", "two", "three"]

        range.to_a –> Creates an array out of the range

        my_array << 20 –> pushes 20 into the end of the array

        my_array << 20 << 21 << 22 –> pushes 20 21 and 22 into the end of the array

        my_array[0..2] –> [1, 2, 3]

        my_array.at(0) –> 1

        my_array.fetch(999, "Not found!!") –> "Not Found!!" . Second parameters returns if element if nil

        my_array.values_at(0,1,2) –> [1, 2, 3]

        my_array.pop –> removes the last element from the array

        my_array.shift –> removes the first element from the array

        my_array.delete_at(1) –> deletes item in position 1

        my_array.delete(1) –> deletes item with value 1. Returns nil if not found

        my_array.delete(1) { "Not Found" } –> deletes item with value 1 and returns "Not found" if the item was not found

    HASH: Same as a dictionary with any kind of key and value
        myhash = { ‘First’ => ‘This is first’, ‘Second’ => ‘This is second’ }

        myhash = Hash.new("not here") –> Creates a hash and returns "not here" when a requested key does not exist

        myhash['new key'] = "this is a new key" –> adds a new element to the hash

        myhash.has_key?(‘first’) –> determines if the key is found

        myhash.has_value?(‘value’) –> determins if he value is found

        myhash.empty? –> true if empty

        myhash.delete['first'] –> deletes the item with that name

        myhash.clear –> clears the hash

        myhash.to_a –> converts to an array of arrays

        myhash.merge –> merges with another hash

        myhash.replace –> replaces the elements of one hash with another

VARIABLES:
    variable = 7 –> 7

    variable = value = 7 –> 7

    a, (b, c), d = 10, 11, 12, 13 –> a == 10, b == 11, c == nil, d == 12

    variable += 1 –> variable = variable + 1

    variable -= 1 –> variable = variable – 1

METHODS:
    convention: methodname? with question mark at the end is used for querying an attribute i.e. France.has_military_victories? methodname! is changing the object that called the method i.e. bob_barker.set_age!(30)

    def methodname(param1, param2)
        #method body
    end
    def method(a = "this", b = "is", c = "fun")
        #optional parameters by assigning a default value
    end
    def method(relation, *names)
        #*names is a param array
    end

    return –> returns a value for the method. If no return element in the method the last value used is returned

    return "more", "than", "one" –> returns more than one value

    variable1, variable2, variable3 = return "more", "than", "one" –> assigns the return values in order to the variables

BLOCKS:
    *A Block is like a method without a name* = Anonymous function

    You can create a block like this:
        { |Parameter| code…. } i.e. myarray.each {|element| print "[" + element + "]…" }
        do |parameter| code…. end i.e. myarray.each do |element| print "[" + element + "]…" end

    PROCS:
        myproc = Porc.new{|animal| puts "Ilove #{animal}!"}
        myproc.call("pandas")

    LAMBDAS:
        myproc = lambda {|x| puts "Argument: #{x}"}
        myproc.call("Texas forever!")

    Diferences between Procs and Labdas:
        – Labdas are strict on the number of arguments when calling
        – Procs make the method that executes them return immediately. Lambda’s don’t yield gives control back to the caller before continuing. Perfect for loops that execute an anonymous function. If in a loop and you call yield inside the loop you can pass the item of the current iteration as an argument to yield, execute the caller code and return after the yield statement inside the loop when the caller is finished executing.

    If you prepend a method parameter with & it makes that parameter a Proc automatically

    Example:

        def method(&block)
            block.call
            yield
        end

        method { print "I’m gettin’ called! " } –> I’m gettin’ called! I’m gettin’ called!

        By using yield, you allow the calling statment to be executed again after the block.call

CLASSES:
    class MyFirstClass < Object
        #creates a class that  inherits from object. Object inheretance is optional, this happens by default.
    end

    def initialize (optional parameters)
        # this is the constructor   
    end

    MyFirstClass.new –> creates the class

    MyfirstClass.new(parameters) –> creates the class with a certain constructor

    @variable –> These are class instance level variables. Private, not visible to the outside
    self points to the current instance

    Classes are never closed. You can add functionality to the string class for instance by simply adding this.

        class String
            def NewMethod           
                #same as extension methods in C#
            end
        end

    Attributes / Properties:
        #readonly property is just another method. Remember that the last value in a method is returned.
        def prop1
            @prop1
        end

        #read/write property
        def prop1
            @prop1
        end

        def prop1=(value)
            @prop1=value
        end

        #how to write an automatic property. This simply creates the get and set definitions for prop1
        attr_writer :prop1
        attr_reader :prop1

        #you can also do this. And vice versa for attr_reader.

        attr_writer :prop1

        def prop1
            #do some processing before returning
            newval = @prop1 + 1
            newval
        end

        *attr_writer and attr_reader simply make it easier to defin a collection of automatic properties’ get and set methods

   Scope:
        When you add the protect keyword to the file in a new line, all the methods that come after it are marked protected, visible by self and derived classes only. You can change back to the the default (public) by adding public to a new line in the file. All methods after that will be public. Same with private.

        class Myclass

            protected # only self derived classes will have access to methods after this line

            def protectedmethod1
            end

            def protectedmethod2
            end

            public # methods after this line are marked pubilc

            def publicmethod1
            end

            def publicmethod2
            end

            private #methods after this line can only be accesed by self

            def privatemethod1
            end

            def privatemethod2
            end

        end

    Constants:
        Simply add the variable directly underneath the class object.

            class MyClass
                CONSTANT_VARIABLE = "test"
                def TestMethod
                    CONSTANT_VARIABLE
                end
            end

    Class Methods (Static / Shared methods)

        class MyClass
            def MyClass.ClassMethod1
                #this is method is a class wide method. available oustide the isntance class
            end
        end

    Class Variables (Static / Shared fields)
        Two @@ before the name make it a class wide field that lives outside of the instance class

        class MyClass
            def MyClass.ClassMethod1
                #this is method is a class wide method. available oustide the isntance class
                @@classfield1
            end
        end

    Modules (Kind of like namespace, but better, more like on the fly inheritance / extension methods / partial classes all in one)

        All you have to do is use include ModuleName to bring in the functionality of the module into your new class

        module Movement       
            def run
                puts "I’m running"
            end
            def walk
                puts "I’m walking"
            end
            def crawl
                puts "I’m so slowwww!"
            end               
        end

        class Man
            include Movement
            def jump
                puts "I’m bipedal and I can jump like a fool!"
            end
        end

        class Sloth
            include Movement
            def flop
                puts "It’s all a lie…all I can do is flop around."
            end
        end

    Files
        You can bring in other files by adding using load or require. Diference is that require only loads it once. Load loads regardless if it has already been loaded. Require is more like signaling a reference need in case it has not already been preloaded.

            load "libraries/myfile.rb"
            require "/home/myaccount/code/libraries/myotherfile.rb"

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