The benefits and horrors of third party controls

.. or how I learned to love the bomb

Don't reinvent the wheel (Photo credit: Wiertz Sébastien)

When developing web applications that should handle all sorts of data and potentially lots of it you might end up in building all kinds of controls for displaying and editing that data. Before you know it you are creating clever pieces of html and even cleverer pieces of backend code to produce that html and an added thick layer of Javascript sauce to make all this work together.
And that brings you into inventing another even cleverer mouse trap or re-inventing the wheel. And that mouse trap or wheel has to be cross browser and multi-functional, databound et cetera et cetera et cetera.
Me, I don't like re-inventing wheels, that has been done so many times already.

So, clear the stage for third party controls

Telerik (Photo credit: martin.linkov)

One these re-inventors of wheels is Telerik. They have various suites of controls that make the life of developers easier. They have menu controls and date(time) edit boxes with calenders and grid controls that you can easily use in your applications. Set some options and bind them to your data and there you go.
I must admit that there is a bit of a learning curve, but with the help of some good examples on the demo site and the ever helpful support desk of Telerik you get everything up and running in no time.

As easy as .. whatever is easy.

But it is not all easy

When you start out all things go smoothly and then you find that on your page with a couple of nested grids you end up with many, many save buttons. As each (sub)grid has one. And thus starts the quest to use only one button to rule them all.

So here is our SaveAll Javascript function.

function SaveAll(button) {
    showLoader();

    $.ajaxSetup({
        async: false,
        cache: false
    });

    $('.t-grid').each(function (index) {
        var grid = $(this).data('tGrid');
        grid.submitChanges();
    });

    $('form').not('.t-edit-form').each(function (index) {
        $.ajax({
            url: $(this).attr('action'),
            data: $(this).serializeArray(),
            type: $(this).attr('method')
        });
    });

    hideLoader();

    $.ajaxSetup({
        async: true,
        cache: true
    });

    return false;
}

 What happens?

• We start by showing a loader div (with spinning gif )on the page and so making it impossible for the user to do something while everything gets saved.
• Then we make sure that all consequent ajax calls are asynchronous as we would otherwise run ito trouble.
• Next we loop through all the grids submit all changes for each grid.
• Then we loop through all the forms (excluding the forms with class "t-edit-form", these are are for inline editing in the grids) and we submit the forms through ajax.
• Finally, we hide the loader div again.

There you are. That was not that difficult.
I have omitted checking for validation errors and what to do when everything is saved. Maybe we need to move to another page?

Well, it almost works, can I go home now?

Almost working is never enough for testers and clients. But is probably even more annoying for me as a developer.
We discovered a weird behavior in our grids. Because we wanted to unclutter our pages we also removed the delete buttons in the grids for removing records and added a column at the beginning of each row with a checkbox so the user can select multiple rows. Then using a delete button in the toolbar you can delete the rows in one go.
Great!
And then we discovered that the value of the first data column was not saved using our button. Other columns worked perfectly. The data was simply not in the request to the server.

After a lot of reaearch, Googling, trial and error

It was clear that the solution was just around the corner. The addition of the checkboxes was the cause. That was easily established, but a solution was more difficult.

Browsing through the Telerik Javascript code and the DOM I tried to add this to part where we are saving the grids.

    $('.t-grid').each(function (index) {
        var grid = $(this).data('tGrid');
        // save any editing rows first
        $(this).find(".t-grid-edit-row").each(function () {
            grid.updateRow(this);
        });
        grid.submitChanges();
    });

That would simply take the rows that are in editing mode and update the data. But no, this tried to update it directly on the server and that would involve additional writing specific server side code to handle those requests.
Close and still no cigar.
The problem was that the edited column was somehow not persisted in the client side data. So that was what  needed to be made sure. Persist all data in client side memory before submitting the grid changes.
But how?

More Googling

Trying evermore results from Google brought me to Paul Reynold's blog. In his post "enhanced batch editing using telerik extensions for asp .net mvc grid control" he explains a lot. Not all of it was relevant for my solutions, but I found a bit of code that helped to fix my problem. Thank you, Paul.

        $('.t-grid').each(function (index) {
        var grid = $(this).data('tGrid');
        // save any editing cells first
        $(grid.element).find(".t-grid-edit-cell").each(function () {
            grid.saveCell(this);
        });
        grid.submitChanges();
    });

I tried to update an entire row (which resulted in a server call) and the solution is to save each cell and these get persisted client side. Just what I wanted.

Lessons learned

I learned a couple of things in this quest:

1. Third party controls are great for making life easier, because all normal functionality is there and tested.
2. Third party controls make things really difficult at times when you want to do something slightly out of the box.
3. Solutions can be found by hunting through multiple search results and reading all the way through these.
4. Never give up.

Multiple submit event handlers on Ajax forms in a wizard style application

.. this was driving me crazy!

I was working on an application (ASP.NET, MVC3) in which I had to implement a wizard like piece of functioality. You know of the 'Next-Next-Previous-Next-Finish'-type.
To make things nice for the user I used AJAX. To make things simpler for me I have one control that is loaded and depending on the page that the user is currently on I load different controls into the form. I return a PartialView and that replaces part
That is all not too complicated and works like a charm.

Uhm, no it doesn't

The first page shows up. I hit the submit button and the page went by smoothly and I could see the ControllerAction being hit. Great! I just increased the page counter and onwards to the next page. The next page arrives in the browser and I hit the submit button again.
Uh oh! Things go wrong now. My ControllerAction is hit twice! Worse even on the next page, it gets hit three times! Oh my, oh my.

Inspection of the problem

Looking at the html closer I quickly discovered that the form had multiple event handlers tied to the 'submit' event. This was the cause of the forms being submitted multiple times.
How come these multiple event handlers then?
Apparently the jQuery Ajax (jquery.unobtrusive-ajax.min.js) has some trouble with the Ajax replacing a part of the DOM and then reattaches some of the existing 'submit' Event handlers. The extra event handler on each page is thus explained.
Root cause is that the AJAX call reloads part of the DOM including the FORM-element and not the content of the FORM and thus somehow the old submit eventhandlers are not cleared. Hence, multiple event handlers.

Okay, so let me Google that for you

Or Bing it. Or Yahoo it.
Many people have encountered similar problems. But none quite the same as mine or at least the provided solutions did not solve my problem. And so I experimented with many solutions and all of them failed.
Thought about somehow preventing all the event handlers but the first to fire. Or just to delete all event handlers except the first. Couldn't find a good way of doing that.

Back to the drawing board

Completely rebuilding the Views and PartialViews to refresh the DOM inside the FORM element was not an option. So that was ruled out.
In the end we decided to go a slightly other way. We decided to step away from a normal submit button as that triggers (all) the submit event handler(s) of the FORM and makes us lose control of the mess we got in. We created a simple button that calls a JavaScript function that does the submit of the FORM through jQuery AJAX. This way we never ever call the submit event handler of the form.
Problem solved.
Please find below the simple JavaScript function that does all the clever stuff.

function onSingleSubmitButtonClicked(button)
{
  var frm = $('form');
  var data =  frm.serialize();
  var url = frm.attr('action');
  var method = frm.attr('data-ajax-method');
  var target = frm.attr('data-ajax-update');
  $.ajax({
    type: method,
    url: url,
    data: data,
    beforeSend: function() {showLoader();},
    complete: function(response) {$(target).html(response.responseText);hideLoader();}
  });
}

We attach this function to the click event of input[type=button] and that is all. Below a step by step run through.

1. The function finds the one form on our page. When you have more forms on a page you may have to pass an id or when the button is inside the form find the parent of the button of type FORM.
2. Next we serialize all the input fields from the form.
3. We then grab the action attribute from the form and use that as the url to post the data to.
4. We read the post or get method from the appropriate method.
5. The update target where we will put the response from the Ajax call into the DOM.
6. Then we make the Ajax call. The serialized data is included and we also show a loader overlay before we send the request and hide it again after the call is complete.

Probably some optimization is possible, but that is a simple solution to the weird problem. Just take things in your own hands. You can't always trust the browser or jQuery do things the way you would expect them to do.