I first met the CEO (Mike Hostetler) and President (Jonathan Sharp) of appendTo back in January while I was at the launch of jQuery 1.4 in Washington DC.
After the unfortunate turn of events at my last job (raided by the FBI & IRS), I was forced to look for a new job opportunity.
One of the first places I thought of working for was appendTo. After several weeks of talks everything worked out and now I am an official employee!
Since Iâve started Iâve done some writing, did an architectural review of a clientâs code, and most recently Iâve been diving deep in developing a JavaScript and jQuery library.
I am really excited about this opportunity. The group of people that I work alongside are top notch! I find it impressive that appendTo has 5 official jQuery Team members working for them.
It looks like Iâll be able to attend the Boston jQuery Conference this coming October 16-17, 2010. I hope to see you there! Sign up while tickets last.
<blockquote>By the way, thank all of you who sent me job leads, contacting me about working with you, or tweeted on my behalf while I was looking for a job. I appreciate all your efforts!</blockquote>
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 ;)
public class ContactViewModel { public System.Guid ContactId { get; set; }
public string Name { get; set; }
public string Email { get; set; }
public string PhoneNumber { get; set; }
public DateTime DateOfBirth { get; set; }
public bool IsMarried { get; set; } }
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.
function isValidPhone(value, name) { console.log('isValidPhone'); var errorMessage = name + ': Invalid Format'; var success = value.length === 14; return [success, success ? '' : errorMessage]; }
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 ;)
public ActionResult Update(ContactViewModel viewModel, FormCollection formCollection) { var operation = formCollection["oper"]; if (operation.Equals("add") || operation.Equals("edit")) { repository.SaveOrUpdate(new ContactViewModel { ContactId = viewModel.ContactId, DateOfBirth = viewModel.DateOfBirth, Email = viewModel.Email, IsMarried = viewModel.IsMarried, Name = viewModel.Name, PhoneNumber = viewModel.PhoneNumber }); } else if (operation.Equals("del")) { repository.Delete(new ContactViewModel { ContactId = new Guid(formCollection["id"]) }); }
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.
Updated Dialog Object Literal
var updateDialog = { url: '<%= Url.Action("Update", "Contact") %>' , closeAfterAdd: true , closeAfterEdit: true , afterShowForm: function (formId) { $("#PhoneNumber").mask("(999) 999-9999"); $("#DateOfBirth").datepicker(); } , afterclickPgButtons: function (whichbutton, formid, rowid) { $("#PhoneNumber").mask("(999) 999-9999"); } , modal: true , onclickSubmit: function (params) { var ajaxData = {};
var list = $("#list"); var selectedRow = list.getGridParam("selrow"); rowData = list.getRowData(selectedRow); ajaxData = { ContactId: rowData.ContactId };
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.
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.
<div></div> 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.
<h4>ASP.NET MVC Contact ViewModel</h4> First lets take a look at our ViewModel which will drive the rules of our client-side validation.
<pre>using System; using System.ComponentModel; using System.ComponentModel.DataAnnotations; using System.Web.Mvc;
namespace jQueryUnitTestingFormValidation.Models { public class ContactViewModel { [HiddenInput(DisplayValue = false)] public System.Guid Id { get; set; }
[Required(ErrorMessage = âName Requiredâ)] [DisplayName(âNameâ)] [StringLength(50, ErrorMessage = âName must be less than or equal to 50 charactersâ)] public string Name { get; set; }
[Required(ErrorMessage = âEmail Requiredâ)] [DisplayName(âE-mailâ)] [StringLength(50, ErrorMessage = âEmail must be less than or equal to 50 charactersâ)] [DataType(DataType.EmailAddress)] [RegularExpression(@â^([a-z0-9!#$%&â+/=?^_{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_{|}~-]+)@(?:a-z0-9?.)+a-z0-9?\s;?\s)+$â, ErrorMessage = âEmail must be validâ)] public string Email { get; set; }
[Required(ErrorMessage = âPhone Number Requiredâ)] [DisplayName(âPhone Numberâ)] [StringLength(50, ErrorMessage = âPhone must be less than or equal to 50 charactersâ)] public string PhoneNumber { get; set; }
[Required(ErrorMessage = âDate of Birth Requiredâ)] [DisplayName(âDate of Birthâ)] public DateTime? DateOfBirth { get; set; }
[Required(ErrorMessage = âRequiredâ)] [DisplayName(âIs Marriedâ)] public bool IsMarried { get; set; } } }</pre> <h4>ASP.NET MVC Contact View</h4> 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.
Note: I am utilizing the Revealing Module Pattern for those of you who might not be aware of it. It is very helpful in splitting up your JavaScript code into testable and reusable modules.
<pre>var contactCreateModule = (function () { var public = {}, dialogWidth = 800;
public.postContactSuccess = function (data, textStatus, xhr) { if (data && data.Success) { notificationModule.displayMessage(true, âYour contact has been created!â); } else { notificationModule.displayMessages(data.Success, data.Messages); } };
public.postContactError = function (xhr, textStatus, error) { var errorMessage = exception ? exception : xhr.statusText; notificationModule.displayMessage(false, âThere was an error creating your contact: â + errorMessage); };
return public; } ());</pre> <h4>Classic QUnit Style Tests</h4> 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âŚ
<div></div> 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.
<div></div> 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.
test(âWhen New Contact Button Clickedâ, function () { //Arrange
//Act $(â#createContactâ).click();
//Assert ok($(â#createDialog:visibleâ).length, âDialog Should Displayâ); ok($(â#Name_validationMessage:not(:visible)â).length, âName Validation Should Not Displayâ); ok($(â#Email_validationMessage:not(:visible)â).length, âEmail Validation Should Not Displayâ); ok($(â#PhoneNumber_validationMessage:not(:visible)â).length, âPhoneNumber Validation Should Not Displayâ); ok($(â#DateOfBirth_validationMessage:not(:visible)â).length, âDateOfBirth Validation Should Not Displayâ); ok($(â#IsMarried_validationMessage:not(:visible)â).length, âIsMarried Validation Should Not Displayâ); });
test(âWhen Click Save On an Empty Formâ, function () { //Arrange $(â#createContactâ).click();
//Assert ok($(â#Name_validationMessage:not(:visible)â).length, âName Validation Should Not Displayâ); ok($(â#Email_validationMessage:not(:visible)â).length, âEmail Validation Should Not Displayâ); ok($(â#PhoneNumber_validationMessage:not(:visible)â).length, âPhoneNumber Validation Should Not Displayâ); ok($(â#DateOfBirth_validationMessage:not(:visible)â).length, âDateOfBirth Validation Should Not Displayâ); ok($(â#IsMarried_validationMessage:not(:visible)â).length, âIsMarried Validation Should Not Displayâ); ok(contactWasPosted, âContact Should Postâ); ok($(â#createDialog:not(:visible)â).length, âDialog Should Be Closedâ); });</pre> <h4>BDD Style QUnit Tests </h4> 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âŚ
<div></div> Here is a slightly zoomed in view of the QUnit Pavlov test outputâŚ
<div></div> 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.
describe(âWhen the contact button is clickedâ, function () { it(âshould display the dialogâ, function () { assert($(â#createDialog:visibleâ).length).isEqualTo(1); });
it(âshould not display name validationâ, function () { assert($(â#Name_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould not display email validationâ, function () { assert($(â#Email_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould not display PhoneNumber validationâ, function () { assert($(â#PhoneNumber_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould not display DateOfBirth validationâ, function () { assert($(â#DateOfBirth_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould not display IsMarried validationâ, function () { assert($(â#IsMarried_validationMessage:visibleâ)).isNotDisplayed(); }); });
describe(âWhen clicking save on an empty formâ, function () { before(function () { $(â.ui-button-text:contains(âSaveâ)â).parent().click(); });
it(âshould keep the dialog displayedâ, function () { assert($(â#createDialog:visibleâ).length).isEqualTo(1); });
it(âshould display Name validationâ, function () { assert($(â#Name_validationMessage:visibleâ)).isDisplayed(); });
it(âshould display Email validationâ, function () { assert($(â#Email_validationMessage:visibleâ)).isDisplayed(); });
it(âshould display PhoneNumber validationâ, function () { assert($(â#PhoneNumber_validationMessage:visibleâ)).isDisplayed(); });
it(âshould display DateOfBirth validationâ, function () { assert($(â#DateOfBirth_validationMessage:visibleâ)).isDisplayed(); });
it(âshould display IsMarried validationâ, function () { assert($(â#IsMarried_validationMessage:visibleâ)).isDisplayed(); }); });
describe(âWhen clicking save on a completed formâ, function () { before(function () { $(â#Nameâ).val(âxNamexâ); $(â#Emailâ).val(âtasty@bacon.comâ); $(â#PhoneNumberâ).val(âxPhoneNumberxâ); $(â#DateOfBirthâ).val(âxDateOfBirthxâ); $(â#IsMarriedâ).attr(âcheckedâ, true);
it(âshould not display name validationâ, function () { assert($(â#Name_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould not display email validationâ, function () { assert($(â#Email_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould not display PhoneNumber validationâ, function () { assert($(â#PhoneNumber_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould not display DateOfBirth validationâ, function () { assert($(â#DateOfBirth_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould not display IsMarried validationâ, function () { assert($(â#IsMarried_validationMessage:visibleâ)).isNotDisplayed(); });
it(âshould post contactâ, function () { assert(contactWasPosted).isTrue(); });
it(âshould close the dialogâ, function () { assert($(â#createDialog:visibleâ).length).isEqualTo(0); }); });
});
});</pre> <h4>Conclusion</h4> 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.
As you may or may not seen on Twitter the last 3 weeks or so, I accepted an offer to work with appendTo, LLC - The Company Dedicated to jQuery where I will be doing JavaScript Consulting as well as other activities.
