Playing around with AJAX and returning data via JSON, I was always getting the error handler called in my AJAX call, despite getting data back from the server.

I noticed that my server code, which I'd quickly stolen from another blog, returned the JSON like this:

            oBuilder.Append("{");
            oBuilder.AppendFormat("'{0}' : {1}", "Minute", "500");
            oBuilder.Append("}");

so this would return
 { 'minute' : 500 }

All good right?

Wrong.  Jquery 1.4 now will parse valid JSON only, and that means the single quotes inside that JSON packet HAVE to be double quotes.

If we need to set an ASP.NET Literal with escaped HTML encoded via javascript's escape() method, we need to use Server.UrlDecode rather than Server.HtmlDecode.

As more and more code goes client-side, it's important to make sure that proper SE principles are still applied.

I'm still using Notepad2 but have to seriously start looking at more advanced(!) IDEs.

At the moment though, I'm happy to make do with stand-alone tools for tasks such as documentation or minimization etc.

For documentation, I've used jsdoc toolkit which you can find here - http://code.google.com/p/jsdoc-toolkit/

To confuse things, the documentation for this documentation-generator is found at the project's previous incarnation - http://jsdoc.sourceforge.net/

The FAQ on how to run it etc is here - http://code.google.com/p/jsdoc-toolkit/wiki/FAQ

Run it using the following command -

java -jar jsrun.jar app\run.js -a -t=templates\jsdoc mycode.js

Tried having a bash with jsUnit today, and got instantly stuck when trying to run a basic test case.

FireFox simply hung, and I really had no idea why.  For the first time, IE8 worked fine!

Thanks to this post, it was straightforward enough to get working.

First you have to modify the jsUnitTestManager.js file, and replace/insert the following code:

function isFF3() {
return (
    navigator.userAgent.toLowerCase().indexOf("iceweasel/3") != -1 ||
    navigator.userAgent.toLowerCase().indexOf("firefox/3") != -1
        )
}

function browserSupportsReadingFullPathFromFileField() {
    return !isOpera() && !isIE7() && !isFF3();
    //return !isOpera() && !isIE7();
}

Secondly, you'll have to disable the draconian security that new FF introduces.  Type about:config in your address bar and then set security.fileuri.strict_origin_policy to false.  This will allow FireFox to access local resources without a problem.

Now it will have disabled the browse to field, so the only way you can run your tests is directly via the address bar, as so:

<path to testrunner.html>?testpage=<path to mytests.html>

Looking at in-line validation for a new website, came across this cracking jQuery component - http://www.position-absolute.com/articles/jquery-form-validator-because-form-validation-is-a-mess/

Couple of gotchas to remember with this:

• It expects the validation class to be FIRST.  So you'll need to remove existing classes and then add them back again at the end.
• It has a bug whereby when you resize/move the window the error divs draw in a new position.  I've fixed this by modifying the buildPrompt() function as below:

 var divErrorId = 'divError_' + linkTofield;
        $('#' + divErrorId).remove();
        
        
        $(divFormError).attr('id', divErrorId);

This very simply identifies each error div according to the field it is displaying against, and removes any existing ones before it adds a new one.

Best practice would be to do this automatically rather than in-line, so you may want to have a function like so:

function registerValidation(id, validation)
{
  //validation has to be the first class declared
  var elementClassList = $(id).attr('class');
  $(id).removeClass(elementClassList);
  $(id).addClass(validation);
  $(id).addClass(elementClassList); 
}

call this from doc.ready in your page as so

$(document).ready(function() {
   
  registerValidation("#txtMyField", 'validate[required,custom[onlyLetter],length[0,100]]');

I haven't tested the above code to any great degree yet, leave a comment if you spot any goofs!

Also, there appears to be another bug if you want to call the javascript directly, so you need to make sure you set the settings like so:

  var settings = jQuery.extend({
      allrules:allRules,               
      inlineValidation: true,   
      ajaxSubmit: false,
      promptPosition: "topRight",   // OPENNING BOX POSITION, IMPLEMENTED: topLeft, topRight, bottomLeft, centerRight, bottomRight
      success : false,
      failure : function() {}
   }, settings);

$.validationEngine.loadValidation("#txtAddressLine1", settings); 



Then you want to check

Code: Select all

$.validationEngine.isError

for an error.

Javascript, as I'm sure you are aware, has no in-built knowledge of classes, inheritance or interfaces as other OO programming languages do.  We have to engineer these using various constructs and work-arounds, in order that we maintain code order and good programming principles.  With more and more code on the client-side in order to provide rich user experiences, this is vital or you'll be condemned to snippet hell. 

Simple View-Controller pattern

Say you want to implement a bog-standard separation of View-Controller logic.  The View is a collection of controls, and directly handles the interaction of these controls before packaging them up and sending them on to the Controller.  In the Windows world, we would raise a custom event from the View which the Controller hooks into, but given Javascript's flexible duck-typing, we can bind the View directly to the Controller and inject a Stub in the future for testing if we should wish.

Anyway, our View has a button.  When the user clicks the button, we want the Controller to know what to do, not the View. 

The View will have a SetController method, which when set, will bind the button's click event (I've omitted the unbind to clear things up) to the appropriate method on the Controller.

Like so:

function RefineSearchView() {
    var _controller;
}

RefineSearchView.prototype.setRefineSearchController = function(newController) {
    this._controller = newController;
    $("#btnStreetRefineFilter").bind("click", createMethodReference(this._controller, "HandleFilter"));
}

NOTE: this is where it gets interesting.  createMethodReference() - what's that all about?  Why don't I just do:

$("#btnStreetRefineFilter").bind("click", this._controller.HandleFilter);

You could expect this to simply bind the click event on to this particular View's Controller's HandleFilter() method.  Non?

Non.  The reason this won't work is because when we bind the click event, we are not in the correct context.  This article - with the suitably majestic title of Object-Oriented Event Listening through Partial Application in JavaScript - will explain it in ways far better than I could!

This is to demonstrate in it's most basic format - we can go on as the article suggests, wave our magic refactoring wand until it transforms from the ugly duckling of createMethodReference into the elegant swan of

this.element.onclick = this.buttonClicked.bind(this);

Controller Handle method

Now we have this set up, it's just a case of implementing our HandleFilter method on the controller:

RefineSearchController.prototype.HandleFilter = function(e) {
    var searchParams = this._searchController.getSearchParams();
    var locality = this._view.getLocality();
    var town = this._view.getTown();

    searchParams._locality = locality;
    searchParams._town = town;

    this._searchController.setSearchParams(searchParams);
    this._searchController.search();

    this._view.updateFilterStatus(searchParams);
}

So now we have completely separated our code into View and Logic sections.  This example was a bit contrived, but you can imagine the situation where our View has to gather information from a number of controls before wrapping these up and sending them on to the Controller in a nice abstract package, similar to the searchParams outlined above.

Not only does this approach give benefits in terms of maintenance, but the stage is now set for unit-testing and programmatically driving your dynamic web page...

Okay, so this is hardly a ground-breaking topic.  But I think it's a valid showcase as to how rich, UI experiences can be delivered via the browser without costing the earth.

Picture the scene - I have a web page with a jquery Grid (FlexiGrid - though I think I will be upgrading to jqGrid due to it's continued developer support - but more on this later) and a toolbar (a very cool Vista style toolbar).

One of the commands available on this toolbar is Print. 

When the user clicks this command, a jquery UI dialog pops up, displaying a selection of valid reports which the user may select.

This reports list is generated from the server.

So, if all of this was to be done as the page loads - well, you can imagine the performance would be unacceptable.  But I want to keep the user experience rich - I don't want them navigating from the grid to another page when they click Print.  So I need to do this using AJAX.

The process is as follows:

 

The Print Button Handler calls the PrintWebService via an AJAX call using some jquery magic as so:

 $.ajax({
                type: "POST",
                contentType: "application/json; charset=utf-8",
                data: "{}",
                dataType: "json",
                url: "http://localhost/PrintService/PrintService.asmx/RenderPrintDialog",

                success: function(data) {
                    $("#printdialoginner").html(data.d);
                    $("#printdialog").dialog("open");
                },

                error: function(xhr, status, errorThrown) {
                    alert(status);
                    alert(errorThrown);
                }
            });

Inside the service, we can get our reports from the server (from the database) at our leisure.  Ish.

Now comes the clever part.  To return the UI, all we're doing is churning back some HTML, right?  But what if we want to be able to visually SEE what we are going to return, at design-time? 

Thanks to Scott Gu, we can get full VS designer support when creating our dynamic UI - check it out - http://weblogs.asp.net/scottgu/archive/2006/10/22/Tip_2F00_Trick_3A00_-Cool-UI-Templating-Technique-to-use-with-ASP.NET-AJAX-for-non_2D00_UpdatePanel-scenarios.aspx

So we create our .ascx controls as normal, pass the path to the ViewManager, and let it get it's hands dirty.  It also keeps a nice, clean MVC separation.

Using this trick, I've been able to deliver a seamless, rich UI without having noticeable effects for the user.  Okay, so there is a slight delay when they bring up the Print dialog for the first time (I know, I've not mentioned caching here but do I need to?) but it's barely noticeable.

We had a review of some client-side code today, as it had started to smell a little "off".

As always, the indication I use when quickly reviewing a design is - how easy is this to unit test?


The problem

Logic all over the place.  Massive "if" statements.  More spaghetti than an episode of the Sopranos.

For our web app, we have a number of "tools"; when the user clicks one, it puts the application into that particular tool mode, which means that any subsequent mouse events have to check which mode we are currently in, and take the appropriate action.  Not only that, but we have introduced a vector view layer (SVG) so we have some tools that update the image layer, some that update the vector layer, and some that update both.

The solution

Stick to established patterns.  When dealing with UI, everything boils down to MVC in the end.


 

What we've done here is separate out each tool into an "Interactor" class.  The View provides the abstraction of each view type, and also the UI events.  The Controller provides the glue to stick everything together.

In Summary:

• The View knows about the different view types, and knows about UI events.
• The View Types know how to render themselves, but are still pretty "dumb".
  
• The Controller knows about UI events, and things called Interactors, but it doesn't know what Interactors are or what they actually do.
• The Interactors know exactly what is going on, they interact directly with the view type and the server.
  

This solution certainly isn't "pure" by any means - there is no M!  And I am in no doubt that we could refine this further. 

But the main thing is we have separated everything out into distinct, logical components that have a defined and related set of responsibilities.

What's more this design is geared for unit testing.  We can test the Interactors independently of the views (by dependency injection, which we will do later) and then add another layer of tests integrating the Controller, and so on.