This post is more of a reference for me than anything else. The Standalone Jasmine runner requires that you manually include any spec files. That gets pretty annoying. So, I built a simple ASP.NET WebPages file that can be used with any ASP.NET 4.0+ application as a light-weight, convention-based Jasmine test runner.

The prevailing practice for moving data between the controller and the view in ASP.NET MVC applications is to utilize a view model. While using a view model from within the view’s ASPX page is quite easy, utilizing it from JavaScript can be more complex. While JavaScript blocks declared inline on the view page can easily consume values from the model, external script files cannot. In order to take advantage of script batching and minimization, you should avoid the use of inline script blocks and instead use external JavaScript files (.js). What happens when you need to reference a value from the view model in your JavaScript though? Since the JavaScript files are not (by default) processed by the ASP.NET pipeline, it isn’t possible for them to leverage the Model; the Model exists server-side, while JavaScript is processed client-side.

I’ve struggled with this limitation since the first preview release of ASP.NET MVC. Here are a couple of the approaches that I tried (and hated):

Place scripts in partial views

Instead of following best-practices and placing JavaScript in an external script file, scripts can instead be placed in partial views. This simplifies the main view by encapsulating the script, and it does allow the script to be re-used. It also allows the script to easily reference values from the view model.

The downside to this approach is that the script cannot be easily minimized or combined, and it can’t be cached by the browser since it is actually rendered inline in the final markup produced by the view.

Pass view model properties through an initialization function

Another approach that I’ve used is to define an initialization function within my external JavaScript files. Any values that are needed by the script can be extracted from the model within the main view, then passed to the external JavaScript through the initialization function.

This approach is also less than ideal. Any values the script requires must be manually extracted from the view model, which makes maintenance more of a headache than it should be.

The ideal solution

The previous two approaches “work”, but they each have drawbacks. The ideal solution would allow the model to be easily consumed by external JavaScript files within a minimal amount of manual work. Adding a new property to the view model should require zero JavaScript in order to expose the new property for use by scripts. It turns out that this is actually quite easy to do….

The right way: serialize the model to JavaScript!

.NET 3.5 introduced the JavaScriptSerializer class for serializing objects to/from JSON. With it, most .NET types can be easily converted into a form that’s easily consumable by JavaScript. Scott Gu introduced a simple ToJSON extension method on his blog which can be used to transform a view model into JSON. When the output of this method is assigned to a JavaScript variable, the properties of the view model effectively become available to client-side script (note that methods defined on the view model, if any, are ignored by the JavaScriptSerializer).

This is a big improvement over the other two approaches I’ve tried (at least in my opinion), but it still requires me to perform this mundane serialization task on each view. An easy improvement is to move it to the master page:

I’m adding support for dragging and dropping rows to jQuery, and as you can probably tell from reading this blog, I’m lazy. I don’t want to reinvent the wheel, so I was not very keen on the idea of trying to implement dragging from scratch. jQuery UI to the rescue! But some quick Googling had me discouraged. I couldn’t find any examples where people had successfully used the draggable and droppable plugins in the manner I wanted. Ugh.

Still, I decided to give it a shot, and low-and-behold, I got it working! The hard part was figuring out some of the options because the jQuery UI documentation is not very helpful. The actual code was quite simple.

If you’ve been following me on Twitter, you no doubt know that I’m fighting rendering problems with Internet Explorer 8. Today, I have finally tracked down one very elusive bug. The problem occurs in liteGrid when a user clicks on a cell to edit it. The contents of the cell are placed with an input element. When the user is finished, they can toggle out of edit mode by pressing escape, enter, or changing the focus to a different element, at which point the input is removed and replaced with the new value. In IE8, the cell width will randomly lose 3 pixels of width when the contents of the cell is changed. Sometimes it occurs when entering edit mode, sometimes it occurs after exiting. Not surprisingly, it works fine in both Chrome and Firefox.

Try that code out here with Internet Explorer 8 and see what you think. Just randomly click on cells like a mad man until you get it to misbehave. Eventually, you should see something like this:

It’s subtle, but you can probably see that the lines between the columns no longer line up correctly on a few of the cells.

The culprit is the “table-layout:fixed” style. Without that style, the table cells do not resize. Unfortunately, liteGrid has to have that functionality, otherwise columns can’t be resized to be smaller than the longest cell value.

“But Matt, you are using jQuery! Couldn’t it be a jQuery bug?!?”

No.

“Are you sure?”

Yes.

“Oh yeah?!? PROVE IT!”

Alright, so I can’t prove it, but I can demonstrate the bug without using JavaScript! Go back to my example, and get one or more cells to contract. After that, start randomly dragging a selection through the table cells. You’ll notice that the cells sometimes snap back to the correct width, while other cells randomly contract. You can inspect the cells with the IE8 Developer Tool to confirm that the width is indeed shifting for no apparent reason. If that’s not a rendering bug in IE8, I don’t know what is.

“Ok, so what now?”

I’m not sure. I’ve made a couple of posts (here and here), and I’m hoping one of them will net something useful. If not… too bad IE. That’s right, I’m not going to waste any more energy trying to fix this. liteGrid still works in IE, you just occasionally get some artifacting while editing cells. I can’t do anything about that; I’ve tried (and failed). This is something Microsoft is going to have to fix in their buggy, standards-ignoring browser.

What I can do though is add a new liteGrid module that will politely suggest that users install a real browser, such as Firefox or Chrome. Look for that module Real Soon Now.

Work continues on liteGrid (I believe that’s the name I’m going to stick with), and in fact so much has changed that I really don’t even know where to start when talking about it. The core has been changed around a bit (for the better), many new modules have been added, an AJAX data provider has been added… it’s been a busy couple of weeks. Today, I thought I would start with something fairly straight-forward: a new module that brings the power of jEditable into liteGrid.

If you recall my previous post, I basically wrote all the cell-editing script from scratch. It worked well enough and was extensible, but as I noted in my article, James Kolpack pointed out that I really did a lot more work than was necessary. So, in what little “spare time” I have, I implemented a module that achieves the same result (click-to-edit) using jEditable instead of custom script. This has several advantages. First, jEditable has a fairly rich set of editors already, and there are even 3rd party add-ons for additional editor types. Second, the goal of liteGrid isn’t editing, the goal is to provide a flexible, extensible, and lightweight grid. Maintaining my own editing library wasn’t going to help me achieve that goal. So, the old InlineEditingModule was thrown away, and JEditableModule has taken it’s place.

There is the usual initialize function that all liteGrid modules must define. Next is an event handler that fires when columns are bound. Finally, there are two helpers: one that is responsible for actually updating the underlying dataItem when a value changes, and one that is called after a cell has been updated. There are also some default options that can be overridden by the liteGrid options (as we’ll see in a second).

If the column isn’t editable, or if it has already been processed (as indicated by the marker class “editable”), nothing is done. Otherwise, an options object is built up that will be passed on to jEditable. If the column type doesn’t have a defined editor in jEditable, a warning is logged, and processing terminates. While jEditable likes to post changes to a URL via AJAX by default, it also supports a callback to handle the save, which is leveraged here with base.saveCell.

For “select” types, which render as dropdown lists, a couple of extra steps are required. First, the options for the select are copied from the column definition. I’m not completely satisfied with this approach as I do not like how jEditable requires you to specify your columns, but it works (for now). Second, the standard textbox editors persist their changes when the user hits the enter key. That doesn’t happen for dropdown lists, so a function is attached that triggers the blur event for the select, thereby triggering the value to persist.

The saveCell function is called by jEditable when the user has indicated that they want to persist a new value:

The underlying data item is retrieved from the parent row so that the new value can be compared to the current value. An event is fired with column, new value, and current value. This allows interested parties to modify the value if they so choose. Ideally, validation could also be handled here, but I haven’t added that (yet). A simple check is performed to see if the new value has changed. If so, the cell is marked as changed, and the data item is updated.

After jEditable has saved the new value using the saveCell method, it calls the afterSave function:

This callback looks to see if the value actually changed, and if so, raises the columnBound event.

And that’s it. It’s considerably simpler than the old method, and aside from a few rendering bugs with IE 8 that I haven’t ironed out yet, I don’t see any reason to use the old InlineEditModule instead of this new JEditableModule.

Crowd: “This is all well and good, but let’s see it in action!”

Yeah, I’m working on that. Once I get it migrated to Google Code, I’ll stand up some demos that people can play around with. Until then, you’ll just have to believe me when I tell you that it works.

My employer has approved the open-sourcing of project “liteGrid”, so that means I’ll be migrating it to Google Code in the Real Near Future. Before I do that though, I need to come up with a final name. I have two candidates right now: liteGrid and Webcel (like Excel, but for the web!). I’m leaning towards Webcel. Anyone have any other suggestions or prefer one name over the other? If so, leave your feedback in the comments.

One of the tenants of liteGrid is that it’s modular, with the core doing as little as possible, and all the richness being layered on top by various pluggable modules. These modules are currently spread across multiple files (one per module). As liteGrid gets closer to “production,” it became time to merge things into a single file (no one wants to include 17 JS files). I also wanted to minify/minimize the scripts to insure faster downloads. The YUI Compressor is a good command-line tool for compressing JavaScript and CSS, and it turns out that it can actually be used to merge files, too. I wrote a simple one-line PowerShell script that does all the magic. Get ready for it… here it is:

At my day job, we’re basically stuck re-implementing Excel in a web environment. (Sidenote: Rob tells me that this is absolutely the correct way to build applications and all web applications should try to mimic desktop applications as much as possible. I don’t like it, but it’s the cards we’ve been dealt, and we have to make it work.) Right now, we’re using jqGrid with ASP.NET MVC, and we’ve got things working at a rudimentary level. However, we’ve found ourselves tripping more and more over jqGrid bugs, limitations, and just plain *pain* when trying to extend it. My take on jqGrid is that it’s too heavy to be flexible, plus it’s not a perfect match for what we’re trying to build in this application. It’s actually becoming a barrier to progress. Though there are alternatives, there is nothing that we’ve found that has all the functionality we need. So, I have now been tasked with creating a new plug-in from scratch that is flexible enough to support our needs. I have dubbed this effort liteGrid (the name sucks because there are 10,000 table plug-ins, and all the good names have been taken).

First, here the requirements I laid out for myself as I built liteGrid. Some of these are based on application needs, but many are just based on design principles that I felt were important:

Must support tree-grid functionality. You should be able to expand and collapse rows.

Must support flexible editing. Items in the grid should be editable, and it should be very clean and easy to customize how things are edited.

Easy to customize. If you want to change something on the grid, it should be easy and straightforward.

Easy to handle formatting. You should have complete control over how values are rendered.

AJAX support. At a minimum, loading and saving data should be doable with AJAX.

Simple. The grid itself should contain very little code.

Event-driven. The grid should be loosely-coupled and use events to pass messages. I was inspired by this article on custom events in jQuery.

jQuery UI support. I hate coming up with themes for anything as I have no artistic inclination (at all), so this is me passing the buck. I’m still not sure how feasible this is as I’m a complete newb on jQuery UI, but hopefully they have something I can leverage.

Before we go any further …

DISCLAIMER

I do not consider myself to be a JavaScript or jQuery guru (yet). This is also a work in-progress. I fully expect it to undergo major changes as additional functionality is added. I’m not claiming (yet) that it’s the best grid out there, just that I like the way it is shaping up. Still, all feedback is welcomed at this point, so feel free to throw rocks at it. Oh, and this may/may not eventually be released in final form. It depends on how my employer wants to handle it. This code is not free and open-source yet, so read it at your own risk (though I really don’t think anyone is going to care).

Getting Started

There is a “right” way to build a jQuery plug-in. And this is it. I used Starter to generate my skeleton plug-in, which saved me quite a bit of time. From there, I modeled the core of liteGrid based loosely on how ASP.NET data grids work. The grid raises events when certain things happen, which interested parties can then listen for and respond to. I wanted to keep the core extremely simple and light, so I also built in support for pluggable modules that hook into the grid to provide additional functionality. The tree-grid, which I’ll show in a future post, is implemented a liteGrid module. Also, liteGrid supports a data provider model. By default, it uses a null provider that returns no data, but you can drop in any objection you want to serve as the provider. By default, liteGrid requires only a single provider method, but as you will see in future posts, liteGrid modules may add additional data provider requirements.

Alright, so code time. Let’s look at the plug-in as a whole before we dive in to the interesting methods:

Aside from the JavaScript added by jQuery Starter, there’s not really much going on. liteGrid is a simple object with only a few methods: init, render, renderRow, buildRow, and insertRowAfter. I expect this list to grow a little bit as I find common functionality that feels like it belongs on the core object, but still, this is far from a complicated object.

Let’s look at the options that are supported right now: columns, dataProvider, modules, missingValue, and rowIdColumn. Columns is simply an array of objects that defines the columns to be rendered. Note that modules can modify this definition to add new columns as needed, as we’ll see in the tree-grid module. Next is the data provider. By default, this is a null provider that just returns an empty array. Users of liteGrid should supply their own provider or use one of the available providers that will “ship” when this thing is finished (including an AJAX provider). Next is the array of add-on modules for the grid. These are initialized by liteGrid and can do all sorts of crazy things. Next we have the value to substitute for rows that are missing a value for a column. This may be a bit of YAGNI creeping in, so I might remove it later. Finally, we have the name of the column (we’re talking data model column) that contains the unique identifier for the row. This should probably renamed to “rowIdProperty” for clarity. Basically, the underlying data objects that are returned by the grid’s data provider must expose a unique identifier, and this is the name of that identifier.

There is the standard jQuery stuff for handling options. After that, all the modules are initialized. This is done prior to *anything* else happening because modules can do whatever they want to the grid. They can override methods, they can change options, they can register event handlers, whatever. Next, we render the grid, and fire a custom event on the actual table element itself that signifies that rendering is complete. Pretty simple!

This method does a lot, so it defers a lot of logic to helpers where it can. First, it wipes out any existing HTML content, and builds a header row for the table based on the column definitions. Next, the data items are retrieved from the configured provider, and a row is rendered for each table. Finally, an event is raised to signify that the grid has changed in some way.

Next is our helper to render a row. I’ll also throw in a related method that builds the actual row:

renderRow simply calls buildRow to build up the DOM tree for the row, then appends it to the table. buildRow is a little more complicated. First, the new row is tagged with a special class that stores the row’s ID. The jQuery data function is also used to store the raw dataItem with the row, making it easy to grab the raw data later. Next, a cell is rendered for each column. Note that the data item may define fields beyond the column specifications, it is completely flexible in this regard. If the data item doesn’t define the column, the missing value is used instead. When it’s all finished, an event is triggered, again on the table element, that allows interested parties to see what’s going on.

The last method our grid exposes is a helper for modules to use. It inserts a row after an existing row in the table:

base.insertRowAfter = function(dataItem, existingRow) {
//Create the row.
var row = base.buildRow(dataItem);
//Insert it.
row.insertAfter(existingRow);
//The table has been changed, so fire the event.
//TODO: Do we *really* want to fire this after every insert? Would
//it be better to have a way to supress the event being fired, and
//allow modules to trigger the event?
base.$el.trigger("tableUpdated", base);
return row;
}

It uses the buildRow function, insuring that all our events are fired, adds it to the DOM, and triggers an event indicating that the table has changed.

And that’s all there is to it! How do we put this grid into action? Here’s a simple example:

Note that this provider actually has a few things that are required by the tree-grid module, which I’ll show in the next post, but liteGrid doesn’t care. It simply looks for matches between your column definitions and the fields on your data items, and skips anything that doesn’t match.

There you have it, liteGrid. Before I end this post, let’s look at a simple module that stripes the rows in the table:

By simply subscribing to events, this module can now apply stripes to the table anytime a row is added or removed. This is a very simple example, and the true power of this functionality won’t really be obvious until the next post, when I show the TreeGridModule.

Alright, so, comment away. What do you think? Any suggestions for improving things?

As I’ve mentioned before, I really, really hate the way most people seem to be creating reusable UI “controls” with ASP.NET MVC. I do not like emitting JavaScript, HTML, etc. from within C# code. It’s cumbersome to create, difficult to really test, and just a real PITA in general.

Based on feedback I received from Rob after my attempts at creating a helper for jqGrid, I decided to take a completely different approach when it was time to wrap another jQuery plug-in: Uploadify. My goal was to minimize the amount of tag-soup embedded in my C# code while still maintaining the ease-of-use of the jqGrid helper, which required only a single HtmlHelper call to go from nothing to full grid.

Well, one painful afternoon later, I think I’ve arrived at something that makes some sense. First, I couldn’t completely eliminate the tag soup, but I did minimize it (I think) while still keeping the thing extremely simple to use and (hopefully) maintain. Let’s start with how you would use it:

The first parameter is the name of the input control to convert to an uploadify control, the second contains all the optional settings you can customize. I prefer to use an options class like this rather than provide 50,000 overloads. By using a dedicated options class, I can add new settings without breaking existing code or having to create new overloads. The options should be fairly self explanatory, but here they are:

The helper uses a StringBuilder (yeah, I hate them, and I’m open to suggestions) to include two JavaScript files. The first is the standard uploadify script, but the second is something custom, which I’ll get to in just a second. Finally, the helper outputs a call to initUploadify inside of the page load event, passing in all the options that were specified.

In here, I’ve created a simple JavaScript function that actually calls the uploadify JavaScript plug-in. By using this method instead of using C# to emit the configuration code directly, I’m cutting out a fair amount of tag soup, and I’m wrapping things up in a way that will be easier to change in the future. Hopefully. The down side to this approach is that you have to create a new JavaScript method and include for every plug-in you want to use, but combining the scripts and correctly setting cache headers should reduce the request overhead.

I’m not claiming that this is the best way to do this. In fact, I really hope it isn’t, because I still don’t like it. But I think that I like it better than the approach I took for jqGrid. If you have any suggestions or feedback, please share. Feel free to tell me that I’m doing things completely wrong.

In the project I’m working on, we use jqGrid to display hierarchical records in an Excel-like manner. Changes are queued up on the client and submitted to the server whenever the user clicks the “Save” button. That means a user could make a bunch of changes, then navigate away from the page accidentally, and lose everything they just did. Preventing that is easy enough though, just use this JavaScript snippet:

1: window.onbeforeunload=checkForChanges;

2:function checkForChanges(){

3:var rows = $('#treeTable').getChangedCells('all');

4:if (rows != null && rows.length > 0) {

5:return'You have unsaved changes that will be discarded.';

6: }

7: };

The checkForChanges function is bound to the onbeforeunload event, which is fired whenever the browser window is about to change the page. This includes page reload/refreshes or anything like that. The checkForChanges function uses the jqGrid getChangedCells method to see if there are any unsaved changes. If there are, it returns a message that will be shown automagically in a JavaScript confirm dialog. If there aren’t, it doesn’t return anything, and the user is allowed to navigate without being nagged.

Mailing List

Pluralsight

Matt Honeycutt...

...is a software developer specializing in ASP.NET. He has over a decade of experience in building web applications and is a founding member of The Lazy Developer Group. A life-long learner, Matt remains dedicated to expanding his knowledge of all things related to development. He recently received his Masters of Science in Computer Science. When he's not busy cranking out code, Matt enjoys helping others hone their development skills.