# Monday, April 30, 2012

I have recently started diving in to Kendo UI and have decided to document that dive and blog about it.  So this is the first post in a series dedicated to using Kendo UI in ASP.NET MVC.

Kendo UI is a JavaScript toolset developed by Telerik that leverages jQuery, HTML5, CSS3, and JavaScript to provide rich UI widgets and an MVVM framework that is ‘scary fast’.  The thing that really drew me to Kendo UI in the first place is there native skinning on mobile devices.  Unlike vanilla jQuery Mobile that renders the same iOS-esque view on all mobile devices Kendo UI Mobile applies specific native-looking styles for iOS, Android, and Blackberry.  Over the series of posts I have planned we will cover exactly what Kendo UI brings to the table for both the ‘desktop’ web and the mobile web, but today I will cover getting Kendo UI installed and configured in an ASP.NET MVC application.

Before we dive in to getting the bits I want to prepare you…Kendo UI is not free.  I know, I was surprised by this as well and it actually delayed my dive in to it for a bit.  In all honesty I am still not 100% sure how I feel about it not being free.  What I do know is that as a long time user of Telerik products they produce damn good tooling and there support system is second to none.  If you want to just play around with Kendo UI there is a 60-day free trial available.

Update: I received a comment from a member of the KendoUI team, thanks John, and my statement above needs some clarification.  Kendo UI is dual licensed (GPLv3 and commercial), so although it is not free for commercial use they do support open source development.  You can can get the official terms here: http://www.kendoui.com/get-kendo-ui.aspx

Note: To prepare for experimenting with KendoUI I created an empty MVC 4 project, that of course is not empty, and removed all scirpt and css files (other than Site.css).  I then removed all script and css registrations in _Layout.cshtml.  I did this because I wanted to deal strictly with KendoUI without all the other *noise* of the other script references.

You can download the KendoUI bits here: http://www.kendoui.com/get-kendo-ui.aspx

Once downloaded and unzipped copy the contents of the ‘js’ directory to the ‘Scripts’ directory of your ASP.NET MVC application and the contents of the ‘styles’ directory to the ‘Content’ directory.

Next you need to register the scripts and CSS files that Kendo UI needs in the _Layout.cshtml.

_Layout.cshtml
  1. DOCTYPE html>
  2. <html>
  3.     <head>
  4.         <meta charset="utf-8" />
  5.         <meta name="viewport" content="width=device-width" />
  6.         <title>@ViewBag.Titletitle>
  7.         <script src="~/Scripts/jquery.min.js">script>
  8.         <script src="~/Scripts/kendo.all.min.js">script>
  9.         <link href="~/Content/kendo.common.min.css" rel="stylesheet" type="text/css"/>
  10.         <link href="~/Content/kendo.default.min.css" rel="stylesheet" type="text/css"/>
  11.     head>
  12.     <body>
  13.         @RenderBody()
  14.     body>
  15. html>

That’s it.  Kendo UI is now wired up.  Pretty much the same process as wiring up jQuery.  So now we can do a quick implementation to prove it.

If you followed my lead and created an empty project you you will need to create a controller and a view at this point.

The actual implementation of KendoUI is almost identical to that of jQuery which makes the ramp up time a lot less if you are familiar with jQuery.

Index.cshtml
  1. @{
  2.     ViewBag.Title = "Getting Started With KendoUI - Installation and Configuration";
  3. }
  4.  
  5. <script type="text/javascript">
  6.     $(document).ready(function(){
  7.         $("#datePicker").kendoDatePicker();
  8.     });
  9. script>
  10.  
  11. <h2>@ViewBag.Titleh2>
  12.  
  13. <input id="datePicker" />

As you can see on line 13 I have an input tag with and id of datepicker and then starting on line 5 I have my document ready function that selects the control with id of datepicker and calls the ‘kendoDatePicker’ function it.  The result is below.

 

KendoUI Calendar

In the next installment we will dig deeper into the different controls available in Kendo UI.

If you want to follow along with the source code it is available on GitHub.

posted on Monday, April 30, 2012 2:01:26 PM (Central Daylight Time, UTC-05:00)  #    Comments [14]
# Monday, April 23, 2012

Having been a part of many large enterprise ASP.NET MVC application implementations using test driven development I learned early on that separating your controller classes into a their own project significantly reduces the noise in your web project.  It wasn’t until a recent talk I gave to user group in my region that I realized that this isn’t a widely adopted practice.  For large applications with a lot of developers and a complex architecture I highly recommend it. 

Putting your controllers in a separate assembly is very straight forward.  First create a controllers project in your solution and then you just need to update your route registrations to tell them where to look for the controllers.

  1. routes.MapRoute(name: "Default", url: "{controller}/{action}/{id}",
  2.                 namespaces: new[] {"[Namespace of the Project that contains your controllers]"},
  3.                 defaults: new {controller = "Home", action = "Index", id = UrlParameter.Optional});

In order to tell ASP.NET MVC where to look for your controllers when registering your routes you use the ‘namespaces’ parameter of the MapRoute method as illustrated above.

I know that the concept of putting controllers in a separate assembly is a bit controversial and everyone seems to have a strong opinion either for or against, so let me know what side of the fence you fall on.

posted on Monday, April 23, 2012 8:02:14 AM (Central Daylight Time, UTC-05:00)  #    Comments [12]
# Monday, April 16, 2012

Back in 2009 I published ReSharper Live Template For Creating Unit Test Stub.  A lot of things have changed since 2009, including my templates.  Since I am doing another series of presentations on Test Driven Development I thought I should get these out because people always ask for them.

As stated in my original post these templates are a way for you to create unit test names that help in describing the true intentions of the test and also to provide a common unit test format that will make reading and comprehending your unit tests easier on everyone.  And of course as lazy developers any redundancies should be automated!

The first template is for a unit test that does not have specific input criteria.

Test w/out Input Criteria
  1. [TestMethod]
  2. public void $MethodUnderTest$_Should_$ExpectedResult$() {
  3.     //Arrange
  4.     $END$
  5.     //Act
  6.     //Assert
  7. }

The second template is for a unit test that has specific input criteria.

Test with Input Criteria
  1. [TestMethod]
  2. public void $MethodUnderTest$_Should_$ExpectedResult$_When_$Condition$() {
  3.     //Arrange
  4.     $END$
  5.     //Act
  6.     //Assert
  7. }

You can take the two templates and create new Live Templates and map to whatever key stroke combination you wish.  I use ‘tt’ and ‘tw’.

Note:  I have been using these Live Templates since ReSharper 3 and I am currently using them in the latest build of ReSharper 6 without any issues so you should be good to go.

As always if you feel these can be improved on or have other Live Templates you want to share let me know in the comments below.

posted on Monday, April 16, 2012 7:09:59 AM (Central Daylight Time, UTC-05:00)  #    Comments [1]
# Monday, April 09, 2012

The week of March 25th – 31st was one of highs and lows for me. 

The Good

Monday through Thursday I was in Las Vegas to speak at VSLive.  The conference was a blast.  Awesome speakers, interesting content, and fun events.  Not to mentioning the networking with my peers.  My talk on Thursday went very well and I received great reviews.  Oh yeah, and I was upgraded to First Class on both legs.  Life was good!

I left Las Vegas immediately after my talk and was back at work on Friday morning…uneventful day.

Saturday I got up bright and early and headed to Milwaukee for Deeper In .NET.  I have attended Deeper In .NET many times and it is always a great event.  This year was lucky enough to be chosen as one of five speakers for the day long event.  The event went very well until 20 minutes into the last presentation of the day…mine.

The Bad and The Ugly

I was doing my Reach The Mobile Masses With ASP.NET MVC 4 and jQuery Mobile, the same presentation I did 2 days earlier in Las Vegas and using the same machine.  The trouble started with VS11 Beta creating half of a solution when I went to create a new MVC 4 project with the mobile application template.  I was able to skip over that issue with out too much trouble.  Shortly there after the machine started acting wonky and I was starting to get that feeling in the pit of my stomach, you know the one, and it happened…BSOD!  NOOOOOOOOOOOOOOOO!

After the initial feeling of dread it was time to boot back up and quickly get back into it it…until I realized the machine was not powering back on.  And my heart sank!  Here I am in front of over 300 of my peers with a neon #FailWhale sign pointing directly at me.

In an attempt to salvage things I started taking questions of the audience and for about 10 minutes that was going well…until the microphone died.  Seriously!  it was just not meant to be.  The event organizers finally threw in the towel on me and declared it a KO, and swag time.

The Lessons

  • As that was my first huge fail in public speaking I learned that I handle myself fairly well under pressure (I think)
    • At first I had the urge to pack up after the BSOD, but then realized that these people came to learn and the least I could do is do my best to answer their questions.
  • People are nicer and more respectful than I give them credit for.
    • Multiple people asked if I wanted to use their machine once mine puked.
    • At least 10 people came up to me afterwards and offered their condolences.
    • Not one negative tweet came across the events Twitter hash tag.
    • No one threw tomatoes or empty bottles.
  • Always have presentation materials available on an external device of some sort in case of emergency machine swap.
  • Don’t trust beta software for coding heaving presentations.  (I was using VS11 beta and MVC4 Beta)
  • My deodorant works as advertised.
  • In the end all you can do is “Smile and wave boys.  Smile and wave.”
posted on Monday, April 09, 2012 7:52:40 AM (Central Daylight Time, UTC-05:00)  #    Comments [3]
# Monday, April 02, 2012

I am very honored and excited about leading up the efforts for the next Midwest Give Camp.  For this installment we have been lucky enough to team up with the folks at That Conference and are hoping to ride the hype and excitement of this awesome event for another successful and rewarding Give Camp.

The Give Camp will be held at the Kalahari Resort in Wisconsin Dells, WI Saturday August 11th through Sunday August 12th, the weekend leading into That Conference.

We are working with an awesome charity that will no doubt be very familiar and close to a lot of your hearts and once we have all the details ironed out I will be going public with them.

For now block off the dates on your calendar and stay tuned for more details! 

posted on Monday, April 02, 2012 8:06:18 AM (Central Daylight Time, UTC-05:00)  #    Comments [2]