Here it is, my talk on CoffeeScript from RedDirt.js, titled “CoffeeScript is for Closers.” Click on the embedded player below to watch the video (40 min), or click here to view it on Vimeo.

CoffeeScript is for Closers from Brandon Satrom on Vimeo.

Here are the links I shared at the end of the talk:

• Slides
• CoffeeScript Website
• CoffeeScript Annotated Source
• CoffeeScript Koans
• Smooth CoffeeScript Book
• Jeremy & Brenden @ JSConf 2011
• “Harmony of my Dreams” by Brendan Eich

I would love to hear what you think, so let me know in the comments, below.

Over the last several months, I’ve been spending a lot of time in Node.js. It started with my Knockout.Unobtrusive and Pinify plugins, which I ported to CoffeeScript, leveraging Node to set-up Cake builds and testing via Qunit. As a part of that effort, I also wrote my own Node package for sending Growl notifications on Windows, 80s Hair-band style. It’s called wingrr, and you can get it at http://github.com/bsatrom/wingrr, or just run “npm install wingrr” in a console window.

Recently, I’ve been working on a few other projects–one, a simple port of the node_chat application to CoffeeScript as an excuse to start using Jasmine; and another project using express and jade that I’m just getting rolling on this week. More on that one later.

In the meantime, I wanted to share something I learned while writing Jasmine tests (using the jasmine-node package) for the node_chat application. node_chat is a simple chat server (a node chat server, who would have thought?) implementation and, as such, it relies on standard output, or stdout, to report errors and information to the “user.” For example, one method provided by the server for this application is “listen,” which, given a port and optional host, will listen to all http traffic at that location. Here’s my implementation, in CoffeeScript. (JavaScript purists can click here for a not-generated-by-the-coffeescript-compiler equivalent)

exports = module.exports

# server logic omitted for brevity

exports.listen = (port, host, callback) ->
  try
    server.listen port, host, callback
    util.log "Server listening at http://#{host or "127.0.0.1"}:#{port}/"
  catch err
    util.log err.message

Notice that I’m calling “util.log” (equivalent to sys.log in earlier versions of Node) to report that the server is listening, or any errors that may have occurred. As expected, this outputs to the console that the server is listening, as you can see in the image below.

This is great, but I wanted to write unit tests that would start and interact with my server, and the best way to verify that my tests passed would be to inspect these messages. I could return these messages from each method, and then inspect the returned value—and I even did that for the first couple of tests—but that would mean that I’ve written production code for the sole purpose of asserting my expectations in a test, which feels dirty.

Instead, I thought it made more sense to hook into stdout myself, and inspect the output for my tests. I hoped that Node might provide some kind of object-based message pump for me to query, but I found no such feature (though do please leave me a comment here if I’ve overlooked something). So I was out of luck in terms of a standard, Node-provided way to inpect stdout from my tests.

Undaunted,  I thought a bit more about my problem. I figured I needed to:

1. Determine the mechanism Node uses to write to stdout
2. Figure out how to “inject” an assertion into that mechanism

With JavaScript, #2 would be a simple matter of “rewriting” the functionality used by #1. So it was really just a matter of figuring out the global objects that Node provides for stdout.

It turns out that Node handles all stdout via a global object called “process.stdout,” and calls to console (ie console.log) or util (ie util.puts or util.log) are merely wrappers for “process.stdout.write.” #1, check. For #2, I was able to override “write” by creating a separate JavaScript module whose only method, “setup,” accepts a callback stub to execute. Here’s my simple implementation (again, click here for the JavaScript version):

exports = module.exports

exports.setup = (callback) ->
  write = process.stdout.write

  process.stdout.write = ((stub) ->
    (string, encoding, fd) ->
      stub.apply process.stdout, arguments
      callback string, encoding, fd)(process.stdout.write)

    return -> process.stdout.write = write

Notice that my callback has access–via the string parameter–to the message being written to stdout. This is the value I’m passing into util.log above; and the value that I wanted to inspect in a test. Notice also that my setup method returns a function that “resets” process.stdout.write back to its original state. You’ll want to call that function after each test, otherwise your callback will fire for every write in your current instance of Node.

Once I had this module in hand, I was able use it in my tests. Here’s a Jasmine test for ensuring that calling server.listen emits the correct message:

server = require '../js/server'
hook = require '../js/hook_stdout'

describe 'chat server', ->

   it 'should listen at localhost on a port I specify', ->
     unhook = hook.setup((string, encoding, fd) ->
       expect(string).toContain 'Server listening at http://127.0.0.1:3001/'
     )
     server.listen '3001'  	
     unhook()

Given the current string provided to stdout, and thus, my callback, I was then able to call Jasmine’s expect() method and toContain() to assert that the string my server is outputting is the one I expected. Notice also that I call hook.setup just before I need it, and assign it to the local variable “unhook.” After my initial call to server.listen, I call unhook as a function, which resets writes back to their original state.

Now I can inspect stdout in my automated tests quickly and easily, and I’ve done all of this without having to modify my server code in any way to accommodate my tests. Feels like #winning to me. Hopefully you’ll find it useful, as well.

That’s that. Not a lengthy, or earth-shattering posts, by any means, but I thought it was worth sharing for anyone doing unit testing in Node applications. If you are, and you’re using a different or better approach for asserting stdout, please let me know by leaving a comment below!

On October 8th, 2011, in Austin, TX, we held the first HTML5.tx event. We sold all 250 tickets two weeks ahead of time, and had over 240 people show the day of the event.

For an unproven conference, it was (and I know I’m biased) a smashing success.

Photos of the event have been posted on Flickr here.

For some nice conference recaps, see here, here, here, here and here.

Our Pals Gavin and Martin from Drifting Creatives have a nice Portfolio page up for HTML5.tx that you can see here.

We’re working on getting the videos up on the site, where they will be available for free. In the meantime, Clark has published the recording for our HTML5 Smackdown session  with the Drifting Creatives guys as Episode 61 of the Developer Smackdown podcast. Check it out here.

If you attended HTML5.tx, and haven’t rated your sessions yet, it’s not too late.

Beyond that, I thought it best if—rather than trying to recreate the emotion of the event three weeks later—I posted the email I sent to all of the volunteers on our public DL the Monday after the event. Here it is, in near-entirety:

To the HTML5.tx Planning Committee and friends,

This weekend, over 240 people came together to learn from one another. You created a place for them to do that.

Over 40 people joined us for the kickoff on Friday. 75 stayed late on Saturday. You all made them feel welcome, helped start and continue the many conversations this unique conference enabled.

Close to 50 sessions were proposed for 14 slots. The final speaker slate represented some of the best web developers and designers, not just in Austin, but across Texas, and all the way to San Francisco and New York. You ignored the unproven state of our conference and pushed for the best content and speakers we could find.

More than half of the attendees participated in at least one open space session. Fourteen sessions were proposed, meaning that 50% of the content at the conference was created by attendees. You insisted that we provide an open space, brought in one of the best facilitators around, and encouraged us to make open space an important part of the conference by making it the focus of the keynote.

Countless people this weekend, from speakers to attendees alike, noted that this was one of the most well-organized, valuable conferences they had been to, local or otherwise. You made that happen by always thinking about our attendees first, and making sure no detail was overlooked. Though I’m sure each of us has a mental list of things we can improve upon next time, don’t miss this chance to feel good about everything you did right.

Thank you, Derick Bailey, Jake Smith, Nola Stowe, John Teague and Mike Wilcox for speaking up on this list and providing your input as we planned in public.

Thank you, Alan Stevens for bringing open space to a new audience, and for truly being a part of this conference, instead of just “the talent.”

Thank you, Clark Sell, for being my partner in crime and co-organizer of this conference. Always a pleasure, my friend. Next up, HTML5.wi. Beer, brats and JavaScript.

Thank you, Gavin Brahman, Jeff Carouth, Keith Casey, Sharon Cichelli, Sam Hooker, Martin Hooper, Robert Stackhouse, Tim Thomas, Jake Wong for being part of the planning committee and for making so much happen. Each of you made a much larger impact on this event than you likely realize. Thank you for putting up with my quirks, for your encouragement throughout, and for pushing this to be the best conference it could be.

Thank you, Keith Casey, Kyle Simpson and the growing HubAustin community, for allowing us to close at your facility. Consider HTML5.tx your biggest fan and promoter!

In spite of what the 10:01 entry on the battle plan might have read. I will be doing this again, and I sincerely hope to have you alongside me.

HTML5.tx. 100% Pure. Indeed, it was, because of each of you.

Thank you, thank you, thank you.

Brandon Satrom

Unretired Conference Wrangler

We are planning to do this again. Hope you’ll consider joining us!

The article was about HTML5 Web Forms, essentially the new input types (email, tel, number, date, etc.), new attributes (autofocus, placeholder, etc.) and new form validation goodies (required, pattern, formnovalidate, etc.). It was a fun article to write, and it’s slated to drop in early November.

One of the questions that often comes up from .NET developers when I talk about HTML5 Web Forms is how these features integrate with ASP.NET Web Forms or MVC. In the article, I speak briefly about updates like VS 2010 SP1 and the mouthfully-named “Reliability Update 1 for .NET Framework 4,” and Scott Hunter has a nice, succinct blog post that covers both, and which you can check out here.

What I wasn’t able to cover in the article, though, was some specifics around using these new input types and attributes with ASP.NET MVC, specifically how one would use these with Strongly-typed HTML helpers in MVC. That’s the purpose of this post.

But first, since the article isn’t out yet as I’m writing this, a quick primer on HTML5 Web Forms for those not familiar.

What’s HTML5 Web Forms?

HTML5 Web Forms (one of the earliest pieces of what we now call “HTML5”) lives in the official W3C HTML5 Specification, which you can read yourself at http://www.w3.org/TR/html5/forms.html. A significant portion of the specification is dedicated to new types and content attributes for the input element, which can be found here: http://www.w3.org/TR/html5/the-input-element.html. For a more digestible resource on HTML5 Forms, I recommend the excellent Forms chapter (“A Form of Madness”) from Mark Pilgrim’s HTML5: Up and Running.

The specification introduces 13 new input types (<input type=”?” />) for use in our forms. Here’s the list:

Each of these new types comes with some interesting behaviors and features. Each also has varying levels of support in the major browsers, but since I cover that in depth in my article (and others have online), I’m not going to rehash it here. For the purposes of this post, let’s assume that I’ve decided to use these new features, am using feature detection (either rolling my own or via Modernizr) and have chosen a polyfilling library or two to fill the gaps in functionality back to older browsers. Of course, I probably should point out that there’s no reason NOT to use any of these new types today. If an older browser encounters a type it doesn’t recognize, it will just change the type attribute to “text,” which is what you’re already using. But newer browsers get all of the built-in validation and presentation provided by the browser.

Using HTML5 Web Forms

All you need to do to get started with HTML5 Forms is use any of the new input types or attributes on a form. Let’s take a look at the markup (snipped a bit) for a sample form (coincidentally, the same form from my article)

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

Here’s the resulting form:

You probably noticed a few new things in the markup above, and I’ll summarize them briefly here (again, without detracting too much from the point of this post):

1. New type=”” values on inputs (email, url, tel, date and number) – All of these do exactly what you’d expect them to.
2. A “required” attribute – Tells the browser that this field must have a value before the form can submitted
3. An “autofocus” attribute – Notifies the browser that a given field should automatically receive focus (a cursor) when the page loads
4. A “placeholder” attribute – Instructs the browser to overlay hint text when the field is empty. The first three fields above us this, as you can see from the screenshot.
5. A “pattern” attribute – Provides a regular expression for the browser to use when validating the form. Above, I’m telling the browser that I’ll only accept telephone numbers in “(xxx) xxx-xxxx” format.
6. “min” and “max” attributes – For type=”number” the minimum and maximum allowed values for the field to be valid.
7. “A “formnovalidate” attribute – Tells the browser to turn off validation for a submit field. In this case, I use the “Save for later” button to allow the user to save an order in process and return to it later.

In addition to what I’ve listed above, a few of these fields provide some automatic validation when I invoke their type. The email field must contain a valid email, url a valid URL, etc.

Enter ASP.NET MVC, Stage Right

As great as these new features are, if you’re using ASP.NET MVC, you’re probably asking yourself a couple of questions right now.

1) How do I use this with strongly-typed HTML helpers?

2) How do I use this with existing DataAnnotations on my model?

Let’s take a look at each of those in turn.

HTML5 Forms and HTML Helpers

If you’re a fan of the HTML helpers in ASP.NET MVC, you probably don’t type this very often

<input type=”text” id=”orderName” />

And instead prefer something more like this:

@Html.TextBoxFor(m => m.Name)

Or even just Html.TextBox.

In the case of our first element, the Name field, using this with the new HTML5 attributes is easy:

@Html.TextBoxFor(m => m.Name, new { required = "required",

                      autofocus = "autofocus",

                      placeholder = "ex. Huggie Reyes" })

This will emit effectively the same markup as the original, raw field. So the good news is that, as you would expect, the new attributes work just fine with the HTML Helpers.

The real problem is with the rest of my fields, all of which use type values not yet fully supported by the HTML helpers (i.e. type=”email”). For these, I can use the @type property in the anonymous properties object, like so:

@Html.TextBoxFor(m => m.Email, new { @type = "email" , required = "required",

                      autofocus = "autofocus",

                      placeholder = "ex. hugo@dharma.com" })

There’s also no reason why you can’t just author markup by hand and keep the input values in sync with your model. But if you’re a attached to the helpers, or if you prefer the type be tied more closely to the helper call itself, the good news is that you have options.

HTML5 Forms and MvcContrib.FluentHtml

The best option, IMO, would be to check out MvcContrib, specifically the FluentHtml features from Tim Scott. FluentHtml has been around for a while, but Tim recently added support for many of the new HTML5 input types and attributes. It’s not yet in an official release, but you can build from the source, grab the MvcContrib.FluentHtml assembly, and follow the setup instructions here. Once we’re all setup,  we can take the raw markup from my order form above and use Fluent Html to yield the following:

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

(While writing this post, I went ahead and implemented the FormNoValidate method on the SubmitButton type, so go grab the latest source for MvcContrib if you’re not up to date.)

Now, when you run the page again, you’ll see that functionally, everything still works as it did before, but you have the benefit of those strongly-typed helpers (and the elegance of the FluentHtml library, if you don’t mind my saying so.)

That’s Nice, But What About My Model Metadata?

In spite of all of this Fluent-y, typed goodness, I’m betting many of you are still bothered by one aspect of using the new input types and attributes on your forms, especially if you’re a fan of annotating your Models with validation attributes (DataAnnotations) like [Required], [Range] and [RegularExpression]. Chances are, when you saw the example markup above with required and pattern attributes, you thought to yourself “Awesome, so how can I use my existing DataAnnotations with these new attributes?”

If you asked that question, You’re probably using MVC Client Validation (introduced in MVC 2) or Unobtrusive Client Validation (introduced in MVC 3), whereby the Model metadata you implement on a given model is used by the framework to generate client validation scripts or data- attributes for use by the client validation framework. These are both fantastic approaches for keeping your validation DRY and consistent from the client to the server, and you should keep using them.

But the reason why HTML5 Forms Validation is so compelling is because it moves client validation squarely into the browser’s lap, meaning that no client-side JavaScript is needed to perform validation before a form is submitted to the server. Of course, script-based client validation should continue to be your first fallback option—with server validation as the last checkpoint—but leveraging in-browser validation for the growing number of users with a modern browser means increased performance and a better user experience.

“That’s great,” you say, “but what about those DataAnnotations?”

With the help of MvcContrib.FluentHtml and a couple of custom behaviors, we can quickly introduce a mechanism that will leverage our model metadata for validation, meaning that we can remove all instances of Pattern(), Required() and Limit() from our example fluent markup above, and the proper HTML attributes will be added on our behalf. Let’s assume that this is my model:

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

And, rather than manually specifying required, pattern and min/max on my markup (which would be repetitive), I want to have those attributes added for me when the appropriate Model attributes are present. MvcContrib.FluentHtml introduces a mechanism whereby I can define a series of behaviors that I want to apply to a single element, or an entire page. I start by implementing the IBehavior<IMemberElement> interface. Here’s an example where I’ve created a RegularExpressionBehavior:

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

Once I’ve created all of the behaviors I need (in this example, I need custom behaviors to fetch Required, RegularExpression and Range attributes), I’ll then create a ViewPage that inherits from ModelViewPage<T> (a type provided by MvcContrib.FluentHtml that I need to use the fluent helpers) and provides the base class with instances of my custom behaviors. Here’s the one I’ve created:

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

Now, all that’s left for me to do is to inherit my ViewPage from the custom ViewPage, and remove the Required(), Pattern() and Limt() calls from my page. For Razor, just add the following to the top of your ViewPage

@inherits FluentHmlt5ViewPage<Order>

Where “Order” is your Model or ViewModel. Obviously, you’ll need to tweak this if you’re using a different view engine.

After removing the statements we don’t need to specify on the view, our markup looks much cleaner, and it’s using Model metadata to set validation attributes for the browser!

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

So there you have it, HTML5 Forms, ASP.NET MVC and Model validation all living in harmony together!

If you’re interested in trying out FluentHtml with HTML5 Forms and the custom behaviors I describe here, I’ve added a basic solution with the 3 custom behaviors and a custom ViewPage object to GitHub as FluentHTML5. Feel free to download it here, and let me know what you think. If its useful, I might expand this with other behaviors.

Knockout.Unobtrusive :: Unobtrusive model binding syntax for KnockoutJS

Over the last week, I’ve spent some time here and there taking the code from my original post and using it as inspiration to create a plugin for Knockout that allows developers to use script-based bindings, rather than the default data-bind syntax. The result is Knockout.Unobtrusive, which I’ve placed on GitHub. I should note here that using Knockout.Unobtrusive isn’t the only option if you’re looking to clean up some of the clutter in your data-bind attributes. Ryan Niemeyer has a great post on cleaning up Knockout Views that I recommend you read. But, if you’re looking to go farther, read on!

This plugin was developed using a test-first approach, with qUnit as my JavaScript test framework of choice. The core plugin itself was authored using CoffeeScript, and the full source can be found here.

CoffeeScript, if you’re not familiar, is a language that compiles 1:1 to JavaScript. I’ve been using it for several weeks now, and I’m sold. During development, I’m running the CoffeeScript compiler locally, with instructions to watch the above coffee file for changes, and to re-compile that file into JavaScript on each change. The resulting JavaScript file is then run against my qUnit tests.

Even if you’re not familiar with CoffeeScript,  the code at the link above should be pretty easy to mentally parse. If, however, you would rather take a look at the JavaScript that CoffeeScript generates, you can check it out here in the source for Knockout.Unobtrusive.

Getting Started with Knockout.Unobtrusive

Getting started with the plugin is pretty easy. First, download the source from my GitHub repository and include a reference to knockout.unobtrusive.js just below Knockout proper.

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

Once you’ve added Knockout.Unobtrusive to your application, you can start moving your existing bindings (data-bind) into a bindings object, and/or create new bindings as needed. I have a full example up on JSFiddle, and embedded below, but let’s take a look at some of the HTML from that fiddle.

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

Similar to the example code used in my original post, Knockout.Unobtrusive ties the View (markup) and ViewModel together through the use of id or name attributes in my markup, and a bindings object passed into the plugin. Using the id and name properties above, we simply need to create a bindings object that “glues together” my View and ViewModel. We can do so by listing pairs of DOM element ids/names and ViewModel properties, organized by Knockout binding type (value, text, options, etc.).

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

You’ll notice a couple of conventions at work here. Each property in the bindings object corresponds to a binding provided by KnockoutJS. Thus, “text,” “value,” “options” and the like are intended to be leveraged in similar situations as the default bindings. Where I previously had an input field similar to the following:

<input type=”text” data-bind=”value: name” ></input>

I would instead do something like this in my HTML:

<input type=”text” id=”name”></input>

Or even this:

<input type=”text” name=”name”></input> //name AND id are supported

and add the following to my JavsScript bindings object:

var bindings = {

  value: [ { name: ‘name’ } ]

};

Of course, Knockout.Unobtrusive uses several conventions, so anytime you have an exact match between an element id/name—like we do above—you can minimize the binding declaration like so:

var bindings = {

  value: [ ‘name’ ]

};

Mixing and matching minimized and expanded properties works, too:

var bindings = {

value: [ ‘name’, { twitterHandle: ‘handle’ } ]

};

Note that Knockout.Unobtrusive doesn’t paint you into a script-only corner. Since the current version is effectively creating data-bind attributes on your behalf, using the bindings you specify, there’s nothing stopping you from using data-bind attributes along with script-based bindings. In fact, v0.1 of Knockout.Unobtrusive doesn’t yet support the creation of bindings in template blocks, so you’ll need to continue to use data-bind for the time being.

Once I’ve defined my bindings object, and I’ve adjusted my markup with id or name attributes where appropriate, I need to call Knockout.Unobtrusive’s createBindings() method and pass in my bindings object. Of course, this needs to be done before I call ko.applyBindings()

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

Now I’m off to the races, using KnockoutJS with clean views and all of my behavior defined in JavaScript! Here’s a working sample, courtesy of JSFiddle.

Note: If you cannot view the embedded Fiddle above for any reason, click here to view it at JSFiddle.net.

For more information about Knockout.Unobtrusive, visit the GitHub repository here. The Readme goes into a bit more detail about currently supported bindings, conventions used in the plugin and plans for future features, so be sure to check that out. Keep in mind that this plugin is v0.1, so there’s still plenty of work to do. So if you have any questions, comments, issues or suggestions, feel free to leave them here as comments, or enter a issue or two at the project site.

So, what do you think? Am I onto something, or totally off the reservation? How would you improve this plugin, or what else do I need to add?

I’m honestly quite jealous that I can’t hop on a plane and get there myself. Devastated, even. To help me feel better, the folks at Skills Matter are letting me give away two free passes to this event. So, if you want one, here’s what I want from you: Leave me a comment on this post and tell me who among the distinguished speakers below you want to see and why. In one week (Monday, August 8th), I’ll pick my favorite responses. Comments are threaded, so feel free to append, modify and enhance your answer as the week rolls on. The only request I have of the two winners is that they send me an email after the event describing their experience so that I can post it here later in the fall. Deal? Great.

If you’re not planning to throw your name in the hat for the passes, fret not, as I also have a discount code for you to use. When registering for the conference, enter the promo code “PROGNET50” to get £50 off this event.

This should be an awesome event, and I can’t wait to hear why you’re exited about it!

EVENT DETAILS
SPEAKERS: Christian Hassa, Gaspar Nagy, Ian Cooper, Sebastien Lambla, Dylan Beattie , Simon Brown, Paul Stack, Damjan Vujnovic, Adam Granicz, Ian Robinson, Mark Rendle, Steven Robbins, Jon Skeet, Nathan Gloyn
WHAT: Progressive .NET Tutorials 2011
WHERE: The Skills Matter eXchange, London
WHEN: 5th-7th Sep 2011 , 9:30AM
COST: £425.00
EVENT TAG: #prognet
FULL DETAILS AND REGISTRATION: http://skillsmatter.com/event/open-source-dot-net/progressive-dot-net-tutorials-2011/

READER OFFER: £50 discount off the ticket price, quoting Promocode: PROGNET50 when registering

PROGRAM HIGHLIGHTS:
Monday September 5th Track 1
09.30 – 13.00 GHERKIN ACCEPTANCE CRITERIA, Christian Hassa & Gaspar Nagy
14.00 – 17.30 AUTOMATING GHERKIN ACCEPTANCE CRITERIA, Christian Hassa & Gaspar Nag

Monday Track 2
09.30 – 13.00 SOLVING THE PACKAGING PUZZLE, Ian Cooper & Sebastien Lambla
14.00 – 17.30 FRONT-END TIPS FOR BACK-END DEVS, Dylan Beattie

Tuesday September 6th Track 1
09.30 – 13.00 LOAD TESTING FOR DEVELOPERS, Simon Brown
14.00 – 17.30 CI TO CONTINUOUS DELIVERY, Paul Stack

Tuesday September 6th Track 2
09:30 – 13:00 TEST-DRIVEN DEVELOPMENT IN JAVASCRIPT, Damjan Vujnovic
14.00 – 17.30 ADVANCED WEBSHARPER TUTORIAL, Adam Granicz

Wednesday September 7th Track 1
09.30 – 13.00 RESTFUL WEB SERVICE DEVELOPMENT IN .NET, Ian Robinson
14.00 – 17.30 INTRO TO NANCY & SIMPLE.DATA, Mark Rendle & Steven Robbins

Wednesday September 7th Track 2
09.30 – 13.00 ASYNC METHODS IN C#5, Jon Skeet
14.00 – 17.30 TBD

More information and registration:
Find more information about this years Progressive .NET Tutorials here. If you would like to register, don’t forget to claim your £50 discount of the ticket price, by quoting Promocode: PROGNET50 when registering.

In both cases, I presented the markup in a pretty server-framework-agnostic way. Meaning specifically that I didn’t use any ASP.NET MVC HTML helpers. I did this on purpose, and to clearly illustrate that KnockoutJS cares not about your server framework. You can use it with ASP.NET MVC, Rails, PHP, Python, whatever.

I did, however, receive a few comments suggesting that I had left the reader or screencast watcher with the impression that Knockout cannot be used with the strongly-typed HTML helpers provided with ASP.NET MVC. This is not the case, so I wanted to take a moment and append my previous post and screencast with some quick examples of using Knockout alongside the ASP.NET MVC strongly-typed helpers.

For starters, let’s take a look at the Speaker Info fieldset from the Add Speaker page I used both in the original screencast and my alternative binding post.

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

Modifying this to use my strongly-typed helper methods in ASP.NET MVC is easy. I just need to use the appropriate helper method, and then set my data-bind attributes as properties in the anonymous object parameter MVC uses for HTML attributes.

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

They key thing to note here is that all of my data-bind properties have been changed to data_bind (underscore instead of dash). Properties in C# cannot contain dashes (-), but underscores are allowed (_), and, by convention, ASP.NET MVC will convert any underscores appearing in the HTML attributes object to dashes.

If I’m using KnockoutJS with the default data-bind syntax—as most are—this is all I need to do to use Knockout and MVC strongly-typed helpers happily together.

If, on the other hand, I’m using Knockout with Unobtrusive bindings, as I detail in my previous post, I need to make a few difference changes. For unobtrusive bindings in Knockout, I’m not specifying data-bind attributes myself, so I can remove those from my helpers, like so:

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

With unobtrusive binding in Knockout, my JavaScript binding object contains a list of fields and bindings to create when the page executes. When the bindings are created, I use a convention to minimize typing so that when my modelBinder sees an input binding of ‘name’, it knows to look for a HTML field with an id=’name’ and, if found, sets the data-bind attribute to “value: name.”

When I’m using the ASP.NET MVC strongly-typed helpers with unobtrusive bindings, this convention won’t work as previously described, because ASP.NET MVC auto-generates field name and id attributes for me, and it uses the Model property name to do so. Since the model property for “Name” is capitalized, my convention breaks.

There are several ways to fix this. I could capitalize the first letter of all of my ViewModel properties in JavaScript, but that would be too easy. Instead, I decided to modify my modelBinder to support first-letter capitalization differences between my HTML and my ViewModel.

Note: If you cannot view the embedded Gist above for any reason, click here to view the embedded code.

To my existing modelBinder object, I added a new private method called getElement, which will attempt to select an element from the DOM given the provided id. If it cannot find that element, it performs a simple capitalization on the first letter and tries again. Once I modify the setBinding method to call this new method, I’m good to go, and I can now used the MVC-generated id attributes with my existing unobtrusive Knockout bindings.

Simple as that! Whether I’m using the default data-bind syntax in KnockoutJS, or doing something crazy, the ASP.NET MVC strongly-typed helpers and KnockoutJS can play together quite nicely.

Click here for the complete Gist used in this post.