Sunday, October 17, 2010

Yesterday I presented at the jQuery Boston Conference 2010. I’ve never attended a jQuery Conference before, so this was an awesome experience all around.
Each year, there is a jQuery UI Introduction talk and this year I was privileged to present the material.

Wednesday, September 15, 2010

I've been working on a project recently where I'm appending the current date to the end of script files so that they won't be cached.

I'm surrounding the code with lots of Unit Tests and I was trying to figure out the best way I could test that the script was actually loaded with the appended timestamp.

How could a JavaScript file tell what URL requested itself? Could the script know what URL make itself load?

Initially I was thinking location.href, but that ends up being the URL of the page the script was loaded on, not the script URL itself. Someone else suggested document.referrer, but that turns out to be the URL that referred the current page.

After a little time passed and several tweets passed by my stream, the correct answer flowed by...

As it turns out, the above technique only works for pages that have the <script> tag manually declared. If you dynamically inject your <script> tags programmatically, then the above technique doesn't work correctly. For my scenario to work, I had to tweak the solution a little bit.

Fortunately, I knew what file I was in, so I could do some partial matching to grab the script tag on the page to look at the src.

alert( $("script[src*=sourcefile1.js]").attr("src") );

The above code depends on jQuery, but I already have it loaded by this point, so it works out fine ;)

Thanks to everyone who helped me along in this fun and interesting problem.

Thursday, July 01, 2010

Introduction

There are a lot of articles out there that show you how to integrate with the jQuery jqGrid Plugin from a listing, paging, sorting approach, but I haven’t seen many that show the integration with the add/edit/delete features that jqGrid offers.

It turns out that it isn’t very difficult to do, but it took quite a bit of digging in the jqGrid API documentation for me to find all the things I needed.

The following article will show how to customize the add/edit/delete modal experience inside of the jqGrid with ASP.NET MVC.

Contact ViewModel

First, you start off with your ViewModel. In this case the following is really bare bones. I haven’t annotated the properties with metadata because I actually do that manually in the jqGrid columns. That isn’t optimal, but it would be nice to have these automatically mapped. That sounds like another blog post ;)

Contact View

The following code setups up the jqGrid to support add, edit, and delete.

The first function you’ll see is a custom validator that checks to see if the phone number has a length of 14. Yes, it isn’t bullet-proof validation by any stretch of the imagination, but its more of an example of what can be done.

Next you’ll see the updateDialog object literal defining the look and behavior of the add, edit, and delete dialog windows. The main property to define is the URL where the AJAX requests will post the data. You can also control whether the dialog closes immediately, if it’s a modal dialog, etc…

The next important thing to notice is the “key: true” property of the ContactId column. If you don’t set this property then the POST for the delete command only send the relative ID that jqGrid generates, not the ContactId that you need. So, this is important ;)

Note:You’ll see some code below setting global properties for the jqGrid such as the title of the dialogs, buttons, etc. If you don’t do this then you’ll get generic titles. I figured these customizations made the user experience a little nicer, but things will work just find without them.

Contact Controller Update Action

The add/update/delete feature takes one URL where you can change the logic based on the operation type. The MVC Modal Binder will map the fields into your ViewModel in most cases. The exception is the “id” that is passed on the delete operation, but there is a way to get around that later in this post ;)

What About Using Complex Keys?

Instead of having ContactId (“key: true”) as your key to delete, you might have a more complex key to identify which item to delete. As it turns out, you can bind to the onclickSubmit event of the add/edit/delete dialog and change what data is POST’ed to the controller.

A nice side effect of this is that you name your property such that the MVC Modal Binder works.

Conclusion

I hope you found the above article of some use in your everyday coding. The jqGrid also provides an inline editing feature similar to what you might experience in an Excel grid. You might look into that if you are interested.

Tuesday, June 29, 2010

I saw an interesting tweet by Remy Sharp (@rem) the other day that sparked my interest.

So, I proceeded to research the Geolocation API and look up various web services that allowed me to utilize JSONP requests from jQuery.

Here is some pseudocode to describe what I came up with…

if (Your browser supports the GeoLocation API) {
if (Geolocation data contains address) {
Use address to populate form (Firefox)
} else {
Use Long/Lat to get address from web service & populate form (Chrome)
}
} else {
Use IP address to get address from web service & populate form (IE)
}

Note:You may notice depending on the browser not all of the fields are being filled out. This is because of the web services that I am utilizing are lacking one or more fields or vary depending on your location. If I find a better web service then I’ll update the script.

Monday, June 21, 2010

Client-Side Unit Testing

The goal of this blog post is to show how you can utilize some helpful techniques to easily Unit Test your Web Application. In this post I will focus on Unit Testing the Client-Side validation rules that ASP.NET MVC generates. You can apply the following techniques to pretty much any scenario, but since this is something I do, I thought I’d share.

Our sample applications is a Contact Manager. At this point we only have a toolbar with a “New Contact” button. When the button is clicked a “New Contact” dialog will appear with several input fields and a “Save” and “Cancel” button. All of the fields are required, so if the user clicks the “Save” button client-validation should verify that all fields have a value.

ASP.NET MVC Contact ViewModel

First lets take a look at our ViewModel which will drive the rules of our client-side validation.

ASP.NET MVC Contact View

Our View is pretty simple. I decided for this sample to not modify the MasterPages that the Templated Helpers use. You’ll see that I’m call the LabelFor, EditorFor, and ValidationMessageFor and organizing them as I wish. If you are interested in a cleaner way to do this you can check out a previous blog entry I wrote entitled Opinionated ASP.NET MVC 2 Template Helpers.

Classic QUnit Style Tests

I initially started this blog post using standard QUnit syntax, but there was something about it that didn’t stand well with me. In particular, I didn’t like how I had a bunch of asserts all lumped together. Later in this article I switch out the classic QUnit-Style with a BDD-Style syntax.

The following are some screenshots from the Unit Tests…

The following is a slightly zoomed in view of the above image. You can see that all the asserts for one particular test are hidden beneath it. You can expand &| collapse the test to see each individual assert.

You can view the unit tests below that generated the above screen shots.
Since I don’t want the $.ajax call to actually occur in my Unit Tests, I swap out the default functionality with a stub function instead in the module setup (which is called before each test). In the module teardown (which is called after each test) I restore the default functionality in case any future test needs it.

BDD Style QUnit Tests

After talking more with Dan Mohl (@dmohl) I decided I wanted to try to find a Behavior Driven style of writing QUnit tests. I know there are several other BDD Client-Side Unit Test frameworks out there, but I wanted to keep to the QUnit runner for now.

So, during my research the author of Pavlov, Michael Monteleone (@namelessmike), let me know about his project, which ended up to be exactly what I was looking for.

The following is the output of my tests using QUnit and Pavlov…

Here is a slightly zoomed in view of the QUnit Pavlov test output…

The structure of the Unit Tests is dramatically different from the above classic Unit Tests.

The first thing you’ll notice is that I am extending the Assertion definitions to clean up some of the assert code that I had in my previous Unit Tests.

I still have the same logic in from the above Unit Tests that was in the setup and teardown methods, but now you can find those in the before and after methods.

The syntax of Pavlov is very readable from an English standpoint. You basically describe some scenario in words, and then split it out into code. It was very refreshing once I put it all together.

Conclusion

The more and more I find myself creating highly dynamic websites, the more I find the need to Unit Test the browser interaction.

I hope you found the above example helpful. I would be interested to hear what tools you use to help Unit Test your client-side code. Please share… it makes us all better :)
You can find some other helpful client-side Unit Testing tools in the Script Junkie article I wrote entitled jQuery Test-Driven Development. In addition I wrote several other jQuery related articles that you can find on Script Junkie.

Note: It was not my intention to exhaustively Unit Test everything in the above example. There are other things I would Unit Test, but to make this example easy to understand in a bite-sized chuck, I limited myself to some simple examples.

Over the past 7 months or so I’ve written 7 articles that are now available on Script Junkie. I was honored to write these articles for the launch of the website. I hope this clues you into why the blog posts on this site have been lacking.

Friday, June 11, 2010

A Typical Switch Statement Scenario

Recently I’ve been working on some highly dynamic User Interfaces and at one point in the project I found my first reflex on a certain task to use a switch statement in JavaScript.

Now, my previous training in studying the Design Patterns has told me that the switch statement is bad. The design pattern drilled into me to resolve the switch statement is the the Strategy Pattern, however, I’ve never used the Strategy Pattern in JavaScript before.

The following example is a simple demo application where I start with a switch statement and then refactor the code later in the blog post to use the Strategy Pattern.

A Simple Super Hero Demo Application

The sample application is a Super Hero creator. You provide a Super Hero name and then you select your Super Hero power. The power can be a variety of things ranging from Flying, Invisibility, to nothing at all. Some of the powers have additional questions (metadata) about that particular power.

Once the Super Hero is created, the application should build up a object with the appropriate power type and supporting metadata. For now, I’m just outputting the object in the Firebug Lite console using console.dir().

First Pass at a Switch Statement Solution

Here is the above application written using a switch statement to build up the Power type and metadata. The solution is fairly simple in nature. I am utilizing the Revealing Module Pattern.

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

The switch solution violates the Open/Closed Principle in that every time a new Super Hero power is added to the list that the same piece of code will need to be modified. This is problematic in that new bugs can easily be introduced as new features are added or as defects are resolved.

Let’s look at a better way to solve the solution.

Refactoring Using the Strategy Pattern

A lof of the code will remain the same in the refactored solution. We mainly want to pull out the switch statement into something that is more maintainable and less error prone for future enhancment.

Abides by the Open/Closed Principle by opening the code for extension, but closing it for modification.

Cons of this Solution

The solution is more complex than the previous switch statement implementation

You might have noticed the use of the eval function. Douglas Crockford labeled the eval function as a Bad Part of JavaScript for some very good reasons, however, in this case I think the benefits it brings in this situation outweighs the risks. With every hard and fast rule, there comes a place and time to examine the benefits and risks.

Conclusion

I found that separating the switch statement logic into the above Strategy Pattern has made my current project much more maintainable and less error prone when adding new features.

How have you addressed similar situation? Have you implemented a different solution to the switch statement problem? Please share with me, I’d love to know!

Friday, May 28, 2010

The Problem

We’ve been using CouchDB in our current project at work and I’ve been using the CouchDB Futon manager more and more lately to create, edit, or delete documents.

After a lot of test data gets into our document store, I end up needing to clear out the documents. I could Delete the whole database with a button, but I’d rather not remove the CouchDB design documents defining custom views.

In order to delete documents from Futon, you have to manually drill down into each document and then click the delete button. I found this very monotonous, so I decided to make a bookmarklet to help me out some.

The Solution

So, I created the CouchDB Potato Bookmarklet (because I’m lazy). The bookmarklet creates a new delete column and provides a “Delete Documents” link to delete all the checked documents. I also added a “Select All Documents” which only selects non-design documents (so that I don’t accidentally delete a CouchDB view). These links can be found in the right navigation column under the “Recent Databases” section.

The Bookmarklet

To use the bookmarklet, drag the following link to your bookmark/favorites list:

Wednesday, May 19, 2010

If you have used ASP.NET MVC any, then you are probably aware of the MVC Contrib project hosted on CodePlex. It is a helpful library that provides useful tools that ASP.NET MVC doesn’t give you out of the box.

Opinionated Input Builders

One of the pieces that I really like is the Opinionated Input Builders that Eric Hexter wrote. The builder allows you to provide one property at a time from your View Model and it will output the label, required indicator, the appropriate input control, and whatever else that it needs to display.

With some CSS styling, the output of the EditorForModel is close to what the Opinionated Input Builder, but there are some problems as we’ll discuss in the next section.

ASP.NET MVC 2 EditorFor

The problem is that I usually don’t want to display or edit my entire model. I often times have things in my View Model that I don’t particularly want to display. I want to rather manually choose which properties I want to display or edit.

Using the above syntax doesn’t quite give the output I was looking for. Only the input controls are rendered (as seen in the following screenshot) instead of providing the scaffolding of label, input, and validation fields like the EditorForModel method provides.

You end up having to provides the layout of the controls and explicitly mention the label, input controls, and validation for each property.

Modify the Template Helpers MasterPage

I soon began to miss the simple syntax of rendering all the necessary code like I was used to when using the Opinionated Input Builders outputted from the MVC Contrib.

All you do, is to override the Master Page that the templates use internally. So, inside my Master Page I layout where I want the label, validation, and input controls to go and then ASP.NET MVC 2 does the rest by resolving which Template Helper to use!

I modified the Master Page some to suite my needs (I use divs instead of tables), but overall it is the same one that he lays out on his blog.

Wednesday, April 28, 2010

jsFiddle

I’ve been using jsFiddle more and more to test and share JavaScript and jQuery code.

Although I love that jsFiddle shows the HTML, JavaScript, CSS, and Results window all at the same time, I also would love to somehow see the output of the console window in the User Interface. Depending on the browser someone views my jsFiddle projects, the console may or may not be defined. I really don’t like alert statements and sometimes it is just easier to console.log() than it is to write out messages to the DOM.

Firebug Lite

So, I’ve been finding myself adding Firebug Lite as a resource to jsFiddle and letting Firebug be part of the rendered output.

If you’ve tried this, then you may have noticed that Firebug auto-opens once jsFiddle is rendered. Seeing that the Rendered section isn’t very big this could be a big problem.

Thankfully, there are several options you can provide to Firebug Lite to customize it’s behavior.

I also like to use JsBin quite a bit and honestly switch between it and jsFiddle quite often depending on what I am doing.

Full Screen Option

One of the features that I really like in JsBin is that you can launch the session to Full Screen and not inside the editor. This is helpful if you want to interact with the DOM with your browser’s debugging tools, minimize any side-effects the editor might be creating, etc…

As it turns out, jsFiddle has this same feature, but you have to know how to get to it. You can just add “/show” to the end of your jsFiddle URL to show it without the editor. To swap back to the edit view you can simply remove the “/show” from the URL.

Full Screen / Editor Toggle Button

Now that we know we can swap back and forth between Full Screen and Edit mode, what I miss is the nice little JsBin link in the upper-right hand corner of the page allowing you to easily swap between the two environments.

As it turns out, I’ve recreated this in jsFiddle by adding the following code to my JavaScript window…

Tuesday, April 27, 2010

In case you haven’t heard from the end of the Rey Bomb #2 Episode of The Official jQuery Podcast, I announced that after 21 episodes I am stepping down as my role of co-host.

Around the time I first joined the podcast I also started to become involved with some intense writing projects (as will become apparent in the near future), although I can’t say much about it right now :)

As a result, I haven’t had much margin in my life. I’ve been running on empty for quite some time and other more important things in my life have gotten the shaft! Unfortunately, one of those was my family and I intend to change that.

I don’t plan to fall off the face of the earth. I plan to refocus on blogging and tweeting. I would like to do some more speaking, but probably not for the rest of the year as baby #3 is coming in August.

I am honored to have been asked to join The Official jQuery Podcast and during my involvement I got to meet many great people that I hadn’t previously known. I am glad to have formed these relationships, and look forward to further investing in them.

This seminar provides an overview of several in-depth concepts that developers need to learn to bring their jQuery development to the next level. We review six things that you should know, such as: "What Is This?", "Am I Referencing the jQuery Object or a DOM Element?", "Understanding Selectors", "Combine and Minify Your Scripts", "Different Ways of Storing Data", and "The Dos and Don'ts of Events". Along the way, we share several helpful websites and tools to make your job as a jQuery developer easier.

For each of the 6 points I started with beginning material and then progressed to intermediate then advanced concepts. When I moved to the next point the content would go back to beginner and then progress to advanced. In this way, I hoped to reach a wider audience with things tips they could take away from the session.

The video from my talk is now available from the Mix10 website. You can watch the video and also download my web-based presentation along with the code I showed.

Unfortunately, the main demo that I wanted to show didn’t work during the presentation. The demo worked the night before & it works now. My guess is that the Picasa Web API was temporarily down during my talk, which is unfortunate. I guess I should have expected something to go wrong. Anyway, overall I think it went well. I had several questions at the end and people stayed after to ask questions as well.

During the presentation I listed several resources that I recommended. I pulled those out and provided them below for quick access them. Some of them I demonstrated during the talk and others I just referred to as good resources you may want to check out.

If you were able to attend my session at Mix10 or watch the above video recording, I would appreciate if you could take a moment to rate my talk on speakerrate.com. Thank you again for voting my session into Mix10.

This eBook reminded me a lot of Cody Lindley’s jQuery Enlightenment in that it split it’s eBook into small bit size installments (known as recipes) that can be consumed either sequentially or on a individual basis. The recipes are organized into situations or problems that you might want to solve using jQuery. This eBook differs from jQuery Enlightenment in that it focuses on the interaction with ASP.NET WebForms, which has a unique rendering of its server controls.

Most of my web development history has been doing ASP.NET WebForms (and more recently ASP.NET MVC) so, I enjoyed reading this eBook. I could understand the situations, problems, and pain points that the eBook addressed. It was nice to see how jQuery can resolve these issues in an unobtrusive and cross-browser way while only requiring a small amount of code.

Each recipe is formatted in the same way…

A challenge that explains the situation, problem, or pain point being addressed

The solution displayed in the form of HTML and jQuery

An explanation of the code broken up in paragraphs, code snippets, and screen shots

A link to a live demonstration

A list of supported browsers for the above recipe

Useful links that are appropriate to further explain features from the code.

I would have written some of the code differently and I did find some performance concerns, but nothing major and when push comes to push and shove many micro-optimizations become moot in the big picture. Selector optimization and looping performance can help make your code become more efficient, but it is really DOM manipulation that will kill your performance in the end.