Craig Shoemaker

Mocking Requests and Data for the Ignite UI igGrid

2013-03-28T17:47:00Z

Sometimes when you are working on a new feature of an application the server and client are either in development at different stages or maybe you just want to work out the particulars of a view in isolation from the server. To make this possible there are a few JavaScript libraries that makes it very easy to mock not only data used in the grid, but also Ajax requests to the server.

The following screenshot is the igGrid filled with random data generated with mockJSON and is served to the grid using the client-side Mockjax library.

When you use an approach like this you are easily able to separate out all mocking behavior so when it’s time to work with the real server you can simply remove the reference to the mocks and then the scripts and grid will work just like normal. The code for the grid remains unchanged whether or not you are using mocked requests and data or not.

Code Download

If you would like to take a look at the source files use for this example, please download them here.

Mocking Requests and Data

In order to truly isolate the client from the server you need to first intercept on the client the requests made to the server. Once the requests are handled locally, then you can construct a mocked response to the page and return it back to the grid.

Mocking requests is handled by the Mockjax library. What’s nice about this library is that as you define routes in the configuration script, any matching requests to the server are intercepted by Mockjax on the client. Even while the client has control of the request, its able to return a response to the page which identical to what the server would provide to the client.

Mocking data is handled by the mockJSON library which uses a template to generate a series of randomized data to send in the response as provided by the Mockjax library.

The following is a sample of a mockJSON template to generate some very simple employee objects:

var data = $.mockJSON.generateFromTemplate({
    "employees|1-5": [{
        "id|+1": 1,
        "firstName": "@MALE_FIRST_NAME",
        "lastName": "@LAST_NAME"
    }]
});

You’ll notice some additional characters in what seems like a normal object literal definition. The | character is a delimiter to tell mockJSON there are some commands included in the template definition. The value that follows directly after the root element (employees) and delimiter is a setting that tells mockJSON how many instances of the mock object to create. The numbers represent a range of random numbers which determine how many objects to create.

The next command in the template is found just after the id label. The +1 command tells mockJSON to increment the value by 1 each time a new object is created. This allows each object to have a unique id.

The template uses keywords (words preceded by an@symbol) to act as placeholders where random data is injected into generated JSON objects. There are many built-in keywords and you can even create your own keywords with custom values available for data generation.

Loading Scripts

To get started, the script loader is configured with known paths to the required JavaScript and CSS files and brings in all the igGrid features used in this example. The comment inside the ready event handler is a placeholder for the code in the next section which is concerned with setting up the grid on the page.

$.ig.loader({
    scriptPath: 'http://localhost/ig_ui/js/',
    cssPath: 'http://localhost/ig_ui/css/',
    resources: "igGrid,igGrid.Filtering,igGrid.GroupBy,igGrid.Paging,igGrid.Sorting",
    ready: function () {

       // setup grid here...

    }
});

Loading the Grid

Now that the page is ready and the scripts are loaded, you can setup the grid on the page. The data for the grid is made available after a JSON response is recognized from the server. Then the columns and features are setup.

$.getJSON('api/employees', function (data) {

    var grid = $("#grid").igGrid({

        autoGenerateColumns: false,
        defaultColumnWidth: "180px",
        dataSource: data,

        columns: [
            { headerText: "ID", key: "id", dataType: "number", width: "80px" },
            { headerText: "First", key: "firstName" },
            { headerText: "Last", key: "lastName" },
            { headerText: "Email", key: "email" },
            { headerText: "Title", key: "title" },
            { headerText: "Active", key: "active", dataType: "bool", format: "checkbox" },
            { headerText: "Workshop Day", key: "workshopDay" }
        ],

        features: [
            { name: "Filtering", columnSettings: [{ columnKey: "id", allowFiltering: false }], mode: "simple" },
            { name: "GroupBy" },
            { name: "Paging", pageSize: 20, pageSizeList: [5, 8, 10, 20, 50] },
            { name: "Sorting" }
        ]
    });
});

This is all the code the page needs to operate. Notice how there is zero mention of mocks in the loader or grid code. There are no flags to alternate data source locations and there is no conditional logic required for the page or the control to differentiate between a “real” scenario and a “fake” scenario. This is the power of working with mocking frameworks – interaction with the mocks is completely abstracted away from the page.

Data Schema

Before diving into the details of the data that is generated for the page, first take a look at a single sample data item that is close to what is generated for the grid.

{
    "id" : 1,
    "firstName" : "Henry",
    "lastName" : "Smith",
    "title" : "Customer Service Rep.",
    "email" : "smith@company.com",
    "active" : true,
    "workshopDay" : "Wednesday"
}

The data generated represents typical information commonly found in an employee database. The next section details how to generate a series of data items structured just like this example.

Adding Mock Support

In order for the page to use the mocking libraries all you need to do is create a new file and add the mock definitions to the file and reference it from the web page. In this example the additional script reference is:

The contents of mock.data.js begin with a self-executing anonymous function.

(function () {

    // add mocks here

})();

The first items added inside the anonymous function are some custom keywords. The first is the &WEEKDAY keyword which is an array of each week day.

    $.mockJSON.data.WEEKDAY = [
        'Monday',
        'Tuesday',
        'Wednesday',
        'Thursday',
        'Friday'
    ];

The next keyword is a list of job titles.

    $.mockJSON.data.TITLE = [
        'Director of Product Engineering',
        'Vice President',
        'Senior Accountant',
        'Accountant',
        'Customer Service Rep.',
        'Sales',
        'Support Engineer',
        'Greeter',
        'Division Manager'
    ];

Then, I added a list of the values for the active flag.

Now, you may be inclined, as I was, to attempt to add some logic into the template. Be forewarned this will not work as you expect. The template is indeed a template and is extracted from the method once and then used to generate each instance of a mock object. In the end, the template is a string and cannot include executing code. (Initially I tried to add a conditional statement to return a random Boolean value, but in the end formatting this value as a keyword is the approach that accomplished what I was trying to do.)

    $.mockJSON.data.ACTIVE = [
        true,
        false
    ];

The following code listing defines a route that is intercepted by Mockjax. When a request to api/employees is made a response is generated on the client and returns as text/json response back to the caller.

    $.mockjax({
        url: 'api/employees',
        contentType: 'text/json',
        response: function () {
            var employees = generateEmployees();
            this.responseText = employees;
        }
    });

The generateEmployees function uses mockJSON to create exactly 54 customer objects. (When you don’t provide a range mockJSON will use the amount you pass in.)

    var generateEmployees = function () {
        var data = $.mockJSON.generateFromTemplate({
            "employees|54-54": [{
                "id|+1": 1,
                "firstName": "@MALE_FIRST_NAME",
                "lastName": "@LAST_NAME",
                "title": "@TITLE",
                "email": "@EMAIL",
                "active": "@ACTIVE",
                "workshopDay" : "@WEEKDAY"
            }]
        });

        return data.employees;
    }

Lastly, the template uses both custom and built-in keywords to provide random data into the objects. The @TITLE, @WEEKDAY and @ACTIVE are all custom keywords and the rest are provided by mockJSON.

Full Mocking Script

Just so you can see it working all together in context, here is the full mocking script.

(function () {

    $.mockJSON.data.WEEKDAY = [
        'Monday',
        'Tuesday',
        'Wednesday',
        'Thursday',
        'Friday'
    ];

    $.mockJSON.data.TITLE = [
        'Director of Product Engineering',
        'Vice President',
        'Senior Accountant',
        'Accountant',
        'Customer Service Rep.',
        'Sales',
        'Support Engineer',
        'Greeter',
        'Division Manager'
    ];

    $.mockJSON.data.ACTIVE = [
        true,
        false
    ];

    // mock requests to employees
    $.mockjax({
        url: 'api/employees',
        contentType: 'text/json',
        response: function () {
            var employees = generateEmployees();
            this.responseText = employees;
        }
    });

    var generateEmployees = function () {
        var data = $.mockJSON.generateFromTemplate({
            "employees|54-54": [{
                "id|+1": 1,
                "firstName": "@MALE_FIRST_NAME",
                "lastName": "@LAST_NAME",
                "title": "@TITLE",
                "email": "@EMAIL",
                "active": "@ACTIVE",
                "workshopDay" : "@WEEKDAY"
            }]
        });

        return data.employees;
    }
})();

Conclusion

Working with mocking libraries gives you ultimate flexibility in being able to test and develop your views independent of the server. When the mock data definitions are present, the page uses mocked data and requests. When references to the mocks are removed, the page works against the server just like normal.

Remote Load-on-Demand with the Ignite UI igTree

2013-03-27T13:25:00Z

The Ignite UI igTree is a powerful client-side jQuery UI widget which has a ton of great features baked right into the control. One of the most valuable features of any tree is its ability to support load-on-demand from a remote server. On a recent project I used the tree to read through a series of XML files which represented many megabytes of data – a remote load-on-demand configuration was must in this situation.

In this example I strip away all the complexities of the file system and server and just isolate the tree to demonstrate how to configure the control for a remote load-on-demand scenario. Along the way I’ll also demonstrate how to use a few very handy JavaScript and JSON mocking libraries to help isolate work with the tree.

The following image shows how the tree works configured for load-on-demand where each node click initiates a request for its children, the node is auto-expanded and selected and the node’s URL data member is shown in the box above the tree.

Note: The URLs used in this example are generated lorem ipsum text. The particulars of how the sample data is generated is detaild in the section Mocking Ajax Requests and Data.

Code Download

If you would like to work directly with the source files used in this example, you can download them here.

Getting Started

The first step is to create a self-executing anonymous function which then sets up the Ignite UI loader. Inside the function, the loader is configured to have known locations for the dependent JavaScript and CSS files. As represented by the comments, when the ready event fires the code to configure the tree is run. The setup for the tree is detailed in the next section.

(function () {

    $.ig.loader({
        scriptPath: 'http://localhost/js/',
        cssPath: 'http://localhost/css/',
        resources: 'igTree',
        ready: function () {

	   // add rest of code here

        }
    });
})();

Setting Up the Tree

Now that the page is ready and all the scripts and styles are loaded, the next step is to set up the tree control. The tree is instantiated by selecting the root element via the #toc selector and calling the igTree function. Next, there are a handful of options required to set the tree in a load-on-demand state. The singleBranchExpanded option tells the tree to only allow one branch of the tree to remain expanded at one time (this feature isn’t load-on-demand specific, but does make the tree easier to use for the user). The dataSourceUrl option tells the tree which URL to use to request data items in the tree. The value of remoteUrl the dataSourceType option designates to the tree that data is coming from a remote source. The loadOnDemand option tells the tree that child items in the tree will only be bound to the tree once a request for the child items is made.

The comments represent a place where the event handlers will go which allow the grid to load data when a node is expanded. Finally, incoming data is bound to the tree based on the mappings defined by the bindings object literal found at the end of the control definition.

var tree = $('#toc').igTree({
    singleBranchExpand: true,
    dataSourceUrl: '/api/items',
    dataSourceType: 'remoteUrl',
    loadOnDemand: true,

    // Add event handlers here

    bindings: {
        textKey: 'title',
        navigateUrlKey: 'url',
        childDataProperty: 'items',
        valueKey: 'url'
    }
});

Event Handlers

The previous code configured the tree for load-on-demand, but the implementation found in the event handlers is what gives the tree the desired behavior.

The nodePopulating event fires when the tree is attempting to load the child nodes of a selected node. The implementation of this event handler sets the dataSourceUrl to a location specific for the selected node each time a new node is being populated. (When the tree is configured for load-on-demand, nodes are only populated when a node is being expanded.)

    nodePopulating: function (event, ui) {
        tree.igTree('option', 'dataSourceUrl', '/api/items?id=' + ui.data.id);
        return true;
    }

The next event is the nodeClick event. The nodeClick event is handled in order to add behavior to automatically expand and select the clicked node. The first line, e.preventDefault(), is needed in order to stop the browser from attempting to navigate away from the page. Next, the tree is given commands to toggle the clicked node (where it will open if it’s closed, and vice versa) and then select it.

The call to the clicked function simply takes the current ui.node.data.url value and prints it on the screen. The last operation is to return false, again to make sure that the control stops any further processing.

    nodeClick: function (e, ui) {
        e.preventDefault();
        tree.igTree('toggle', ui.node.element);
        tree.igTree('select', ui.node.element);
        clicked(ui.node.data.url);
        return false;
    }

Note: Since the settings are being passed to the tree as an object literal, the event functions must be followed by a comma after the closing brace to the function. The full code listing at the bottom of this post shows each of the event handlers in context of the object literal.

Once the tree is set up with these options and the event handlers are implemented, the tree is fully configured for remote load-on-demand.

Mocking Ajax Requests and Data

While the tree is in working order, providing data to the tree can get involved if you need to set up a server side counterpart to handle serving data to the client. A technique I used in this example was to mock the JSON data that is provided to the tree. This is made possible by leveraging two JavaScript libraries. The first library is Mockjax which intercepts Ajax requests made by the tree and allows them to be fulfilled locally - all the while returning an identical response a server would send back to the tree.

The second library I used was mockJSON which is an engine responsible for generating mock data in JSON format based on some rules you provide. The nice thing that once the mocking is setup, all the mocking logic is easily separated from the standard executing code. In this example, moving all the mocking code into a separate file is trivial. When you are ready to remove mocked requests and data, all you have to do is simply remove the reference to the file and the tree will then go back to contacting the server just like normal using the URLs configured in the dataSourceUrl option.

Full Code Listing: Load-on-Demand Demo (index.html)

(function () {

    $.ig.loader({
        scriptPath: 'http://localhost/js/',
        cssPath: 'http://localhost/css/',
        resources: 'igTree',
        ready: function () {

            var tree = $('#toc').igTree({
                singleBranchExpand: true,
                dataSourceUrl: '/api/items',
                dataSourceType: 'remoteUrl',
                loadOnDemand: true,

                nodePopulating: function (event, ui) {
                    tree.igTree('option', 'dataSourceUrl', '/api/items?id=' + ui.data.id);
                    return true;
                },

                nodeClick: function (e, ui) {
                    e.preventDefault();
                    tree.igTree('toggle', ui.node.element);
                    tree.igTree('select', ui.node.element);
                    clicked(ui.node.data.url);
                    return false;
                },

                bindings: {
                    textKey: 'title',
                    navigateUrlKey: 'url',
                    childDataProperty: 'items',
                    valueKey: 'url'
                }
            });

            var clicked = function (msg) {
                $("#result").text(msg.toLowerCase());
            }
        }
    });
})();

Full Code Listing: Mocking Requests and Data (mock.data.js)

(function () {

    // mock requests to items
    $.mockjax({
        url: '/api/items',
        contentType: 'text/json',
        response: function () {
            this.responseText = generateResponse(true);
        }
    });

    // add wildcard mock to capture requests with query string values
    $.mockjax({
        url: '/api/items?*',
        contentType: 'text/json',
        response: function () {
            // randomizes whether or not the response has child elements
            var hasChildren = parseInt((Math.random() * 10), 10) % 2;

            this.responseText = generateResponse(hasChildren);
        }
    });

    var generateResponse = function (includeItems) {
        var data = $.mockJSON.generateFromTemplate({
            "items|5-5": [{
                "id|+1": 1,
                "title": "Item",
                "url": "http://@LOREM.com",
                "items": includeItems ? [] : null
            }]
        });
        return data.items;
    }
})();

9 Interactive Features of the Ignite UI igGrid

2013-03-20T16:00:00Z

Thanks to all who attended my recent session on 9 Interactive Features of the Ignite UI igGrid. There’s a lot packed into the grid and features highlighted in the webinar just scratch the surface on what the grid can do!

Demos Download

If you’re interested in working through the samples I used during the demo, you can download the code here. Please note that you’ll need to setup a virtual directory named ig_ui to host the js and css folder which have all the Ignite UI files in them.

What about the Grid?

There are three ways you can get access to the grid to run the samples:

Use your existing licensed copy of Ignite UI
Download a trial of Ignite UI
Get igGrid for free! (this offer may not always be available)

Once you download the bits and setup the files in your virtual directory, the demos should work unaltered on your machine. The good news is that you can run them by just opening the HTML files from the file system or by running them through a web server.

Enjoy!

Get Started Learning Ignite UI Today!

2013-03-06T23:44:00Z

Anytime you approach a new library or set of controls sometimes it’s nice to get a helping hand. In an effort to make it drop-dead simple for you to learn how to get started with Ignite UI, I am announcing the release of Fundamentals of Ignite UI.

This video series will acquaint you with Ignite UI from some of the high level architectural constructs down to the details a control’s API. The first batch of videos in the series includes 15 videos which introduce Ignite UI as a whole and then moves into working with the particulars of the igGrid control.

Ignite UI Introduction

igGrid Introduction

igGrid Interactive Features

I am splitting up the total of the grids features into interactive, customizable and editable features. This batch just gets you warmed up to the igGrid and then reviews the interactive features. Later customization features will include features like column hiding, merged cells, client templates, column summaries and the like. The last section will take you through the features which support CRUD operations in the grid.

The long-term goal is to go through as many controls as possible, so there’s a lot of content ahead!

Please let me know what you think of the videos and feel free to suggest what you might like to see covered in an upcoming video.

Avoid this Obscure Error when Using the igGrid Control by Selecting the Right Root Element

2013-02-04T21:32:00Z

Instantiating the igGrid control is straight-forward; you can simply create the control with a call similar to $("#grid").igGrid() and pass in grid options depending on your requirements. While it’s easy to construct a new grid this way, it’s also easy to overlook a small nuance which can have a significant impact on how you work with the control. In the end, the HTML element that is selected by the #grid selector makes a big difference on how the control is constructed in markup and how easy it is to work against the grid’s API.

TL;DR

Use TABLEs as the root elements for the igGrid and igHierarchicalGrid

Choosing the Right Root Element

There is a subtle difference between the following markup listings when you are working with the igGrid:

and

The DIV element is often used as a “catch all” container for many Ignite UI controls where the generated markup is injected into the DIV and all interaction usually works as expected. The grid controls are a bit different in that they inherently HTML tables, so using a HTML TABLE element as the control’s root is the most appropriate choice.

Anatomy of the Grid Control

When a new instance of the igGrid control is created on a page the root element is wrapped by a container DIV element. This wrapping DIV element is necessary in order to act as a container for the supporting UI elements associated with the grid when different features are enabled in the grid. For instance, when you enable paging, the paging UI elements are rendered in the DIV which contains the TABLE for the grid. The same is true for group by, multi-column headers and any other additional UI elements required by the grid.

Effects of Differing Roots

To better illustrate the difference between using a DIV as the root element as opposed to a TABLE element, take a look at the following images which depict the markup generated inside a DIV vs. a TABLE element.

Figure 1: igGrid Markup with DIV element as Root Element

Figure 1 is an excerpt of the markup generated by a grid where the root element is a DIV. In order to generate all the required markup for the control, the widget creates the grid container and TABLE element as respective children of the root DIV element. This can propose a problem if you attempt to access features from the grid.

For instance, if you attempt to sort the grid with a call to the sortColumn method such as:

$("#grid").igGridSorting('sortColumn', 1, 'ascending');

You will encounter an error like:

Uncaught TypeError: Cannot read property 'currentSortDirection' of undefined

Now, this is not an error in the control, but rather the object with which was selected as #grid is pointing to a DIV and not the expected TABLE element which produces the error. The resolution is to use a TABLE element as the root of the control.

Figure 2: igGrid Markup with TABLE Element as Root

Figure 2 shows how the markup is generated when with a TABLE root element. Notice that the grid is instantiated as a TABLE element with the ID of grid and it is wrapped with a container DIV element. Now each time the object that is selected against #grid references the table element, which is the grid itself, rather than a container element.

Avoid Errors When Defining Resources with the Ignite UI Loader

2013-01-21T21:58:00Z

When defining resources in the $.ig.loader options, you have the option to explicitly load all the scripts associated with the control itself, load a selection of its features and even a load using a wild card option. When you are loading in explicit features the format of the resources string is very important – the list is comma delimited and spaces are not allowed.

Therefore, when you are loading scripts…

Don’t Do This

$.ig.loader({
    scriptPath: "http://localhost/ig_ui/js/",
    cssPath: "http://localhost/ig_ui/css/",
    resources: "igGrid, igGrid.Paging"
});

Notice how there is a space after the comma where the second resource is loaded. When you try to run this page you’ll get an error that says:

Uncaught Resource ' igGrid' cannot be found. Please check that the resource name is correct.

Do This

$.ig.loader({
    scriptPath: "http://localhost/ig_ui/js/",
    cssPath: "http://localhost/ig_ui/css/",
    resources: "igGrid,igGrid.Paging"
});

Note that the space is now removed and this code now executes as expected.

5 Tips for Configuring Ignite UI Grid Columns

2012-11-14T19:44:00Z

The default settings found in the Ignite UI igGrid make working with data easy, but with a little customization you can quickly change how the data appears in each column.

1. Manually Define Columns

The first step to taking control of how data renders in the grid is to turn off autoGenerateColumns and manually define columns to explicitly set each of the column’s options.

Options available for each column are:

Setting	Description
dataType	Represents the data type of the underlying data for the field being bound to the column.
format	Defines how the grid should interpret the data in the column to format for display in the grid cell.
formatter	References a function that is responsible for formatting the column value.
headerText	Text string that appears in the header of the column.
hidden	Boolean value indicating whether or not the column is hidden from the when the grid is rendered.
key	Points to key value used to look up the data value to render in the cell.
template	String-based template for customizing the contents of the cell.
width	Pixel-based value for the width of the column.

2. Define the format

The format column option allows you to take control over how the data is rendered in the grid for a specified column. Depending on what type of data is provided to the column the format options vary.

Date

The following table depicts how the different format modes render the raw date value of 8/13/2012.

Format	Result
date	8/13/2012
dateLong	Monday, August 13, 2012
dateTime	8/13/2012 3:34 PM
time	3:35 PM
timeLong	3:35:17 PM
MM/dd/yyy	08/13/2012
MMMM	August
mmm-d, yy	Aug-13, 12
yy	12
h:mm:ss tt	3:37:40
dddd d MMM	Monday 13 Aug

Number

The following table depicts how the different format modes render the raw number value of 151324.912834098234.

Format	Result
number	151,324.91
int	151,325
currency	$151,324.91
percent	151,324.91%
#.###	151,324.913
0.000	151,324.913
0	151,325
double	151,324.91

Note: The double format is similar to number, with unlimited maximum number of decimal places.

Other Formats

Format	Description
string	No special formatting – renders the string value as-is in from the data source.
bool	Renders the string ‘true’ when the value is true and nothing when the value is false.
checkbox	Renders a checked checkbox image (not an input element) if the value is true and an unchecked image if the value is false.

3. Use the {0} replacement token for strings

When working with string typed columns, you can use the {0} replacement token to represent the incoming data value in a format string. For example if you want to add the standard prefix of “INV” to an identification string in the grid you can define the format as:

$("#grid").igGrid({
	columns: [
	{
		headerText : "Part",
		key: "PartNumber",
		format: "INV-{0}"
	}],
	autoGenerateColumns: false,
	dataSource: data
});

4. Add a formatter Function

The formatter option points to a function that allows you to evaluate the incoming data value and implement custom logic. The formatter function must take an argument of the incoming value and must return a string.

Consider a grid where you want to indicate whether or not a contact is a minor by adding the string “(minor)” next to the age value in the column. The resulting formatter function would look something like this:

function ageFormatter(age) {
	if(age > 18){
		age += " (minor)";
	}

	return age;
}

To use the function you set the formatter option to point to the function:

$("#grid").igGrid({
	columns: [{
		headerText: "Age",
		key: "Age",
		dateType: "number",
		formatter: ageFormatter
	}],
	
	autoGenerateColumns: false,	
	dataSource: data
});

The formatter function is then run each time a value is bound to that column for each row.

5. Create a Custom Template

If you want to have fine-grained control and use data from other columns in your column format, then you want to create a custom template. The template engine used for grid columns is a string-based template so a simple template which renders a contact’s first name would look like this:

template: "${firstName}"

This approach works well if you are injecting in the data from the given column you are defining. If you want to make data from another column available to your template, then you must include a hidden column which is bound to the key you need in your template. The following template demonstrates how to create a link around the person’s first name using the person’s ID:

$("#grid").igGrid({
	columns: [
	{
		hidden: true,
		key: "ID"
	},
	{
		headerText: "First Name",
		key: "firstName", 
		template: "${firstName}"
	}],
	autoGenerateColumns: false,
	dataSource: data
});

4 Steps to Binding XML Data to the Ignite UI Grid

2012-10-23T15:48:00Z

The Ignite UI Grid is a flexible jQuery and HTML-based grid control that can be bound to many different types of data sources - and XML data is no exception.

1. Get the Data

To begin, you first need to get data on your page. In this case your page needs to have XML either locally available on the page or as the result of an AJAX call.

For simplicity’s sake the code example that accompanies this post has XML data local to the page.

var xmlDoc = '<People>' +
    '<Person Name="Gustavo Achong">' +
        '<Details Age="42" Email="gachong@adventureworks.com" />' +
    '</Person>' +
    '<Person Name="Catherine Abel">' +
        '<Details Age="27" Email="cabel@adventureworks.com" />' +
    '</Person>' +
    '<Person Name="Kim Abercrombie">' +
        '<Details Age="33" Email="kabercrombie@adventureworks.com" />' +
    '</Person>' +
'</People>';

2. Create the Schema

Once you have data available, then you need to create a schema. Since XML is a very flexible data structure schemas are necessary to provide a way for the data source component to know how to interpret the incoming XML.

The searchField option is configured to point to //Person which points to the root of the XML element which represents a record in the grid.

Each of the columns in the grid is mapped to fields in the XML schema. In this case, the root Person element has only one child element with a few attributes that are extracted using XPath syntax to create the appropriate schema.

var xmlSchema = new $.ig.DataSchema("xml", { 
    //searchField serves as the base node(s) for the XPaths
    searchField: "//Person", 
    fields: [
        { name: "Name", xpath: "./@Name" },
        { name: "Email", xpath: "Details/@Email" },
        { name: "Age", xpath: "Details/@Age" }
    ]
});

3. Create the Data Source

Now that the raw XML data is being shaped by the schema, the two are paired together using the data source control.

var ds = new $.ig.DataSource({
    type: "xml",
    dataSource: xmlDoc,
    schema: xmlSchema 
});

4. Bind to the Grid

Finally the grid is instantiated with the dataSource option set to the instance of the data source.

$("#grid").igGrid({
    dataSource: ds
});

Full Source Code

To see it all working together, the following is the full source code.

<!DOCTYPE html>
<html>
<head>
    <title></title>
    <script src="../js/modernizr.min.js"></script>
    <script src="../js/jquery.min.js"></script>
    <script src="../js/jquery-ui.min.js"></script>
    <script src="http://localhost/ig_ui/js/infragistics.loader.js"></script>
</head>
<body>

    <table id="grid"></table>

    <script>
        // The ig.loader is used to load required IgniteUI JavaScript 
        // and CSS resources. It accepts a configuration object that specifies
        // default paths and the components to load into the page.
        $.ig.loader({
            scriptPath: 'http://localhost/ig_ui/js/',
            cssPath: 'http://localhost/ig_ui/css/',

            //string representing which component resources are required
            resources: "igDataSource,igGrid"
        });

        //The ig.loader accepts a function that is called after 
        //all resources are loaded and document.ready has fired.
        $.ig.loader(function () {
                        
            //Sample XML Data
            var xmlDoc = '<People>' +
                '<Person Name="Gustavo Achong">' +
                    '<Details Age="42" Email="gachong@adventureworks.com" />' +
                '</Person>' +
                '<Person Name="Catherine Abel">' +
                    '<Details Age="27" Email="cabel@adventureworks.com" />' +
                '</Person>' +
                '<Person Name="Kim Abercrombie">' +
                    '<Details Age="33" Email="kabercrombie@adventureworks.com" />' +
                '</Person>' +
            '</People>';

            //Binding to XML requires a schema to define data fields
            var xmlSchema = new $.ig.DataSchema("xml", { 
                //searchField serves as the base node(s) for the XPaths
                searchField: "//Person", 
                fields: [
                    { name: "Name", xpath: "./@Name" },
                    { name: "Email", xpath: "Details/@Email" },
                    { name: "Age", xpath: "Details/@Age" }
                ]
            });

            //This creates an Infragistics datasource from the XML 
            //and the Schema which can be consumed by the grid.
            var ds = new $.ig.DataSource({
                type: "xml",
                dataSource: xmlDoc,
                schema: xmlSchema 
            });

            $("#grid").igGrid({
                dataSource: ds //$.ig.DataSource defined above
            });

        });

    </script>

</body>
</html>

Changes to the Help Installers in NetAdvantage 2012.2

2012-10-18T14:19:00Z

Summary

Help installers for Visual Studio 2008 are no longer available
The installer now supports Visual Studio 2010, Service Pack 1 (Help Viewer 1.1) and Visual Studio 2012 (Help Viewer 2.0)
There is a repairable known issue if you have both Visual Studio 2010, SP1 and Visual Studio 2012 installed on your machine

Available Help Formats

With the release of NetAdvantage 2012.2 we have made some changes to the available help installers that accompany our products which use the Visual Studio help format. First, we are no longer shipping help for Visual Studio 2008 (Help 2.X). The help versions that are now available are for:

Visual Studio 2010, Service Pack 1 (Help Viewer 1.1)
Visual Studio 2012 (Help Viewer 2.0)

We require the Visual Studio 2010, SP1 at a minimum because this allows us to ship pre-generated index files, which ultimately speeds up install time for both formats.

Known Issue

If you have both Visual Studio 2010, SP1 and Visual Studio 2012 installed, but do not have the local store setup for Visual Studio 2010, SP1, then the only help that is installed on the system is the Visual Studio 2012 format.

Fix

If you want the help in the Visual Studio 2010 format, then you need to to setup the local store. To do this, launch Manage Help Settings utility under Start > Microsoft Visual Studio 2010 > Tools > Manage Help Settings – ENU. Then select the location you wish to create the local store and press OK.

Once you have setup the local store you can run a Repair mode on the NetAdvantage help installer to register with Visual Studio 2010, SP1.

Alternatively, you could also manually install the help, after setting up the local store, which is detailed in Installing Visual Studio 2010 Help for NetAdvantage for Windows Forms and ASP.NET Products, but the process now applies to all product lines.

Update: If you are running on an x64 operating system, and only have Visual Studio 2012 installed on your machine then the NetAdvantage Platform installer does not all you to install help of any format. This issue is being addressed an we hope to have a fix available shortly.

Ignite UI Grid in the Desktop Browser and iPad

2012-10-12T21:40:00Z

One of the great characteristics of the Ignite UI jQuery grid is how well it works in both desktop and mobile environments. In this video I demonstrate the grid working with a number of interactive features enabled and you can see it working on an iPad as well as a desktop browser.

ReportPlus How-To Videos

2012-09-19T21:10:00Z

Are you eager to get to know ReportPlus? Take a few minutes to check out the following videos that cover the basics as well as some in-depth features:

iPad + You = Enterprise Reporting

2012-09-19T13:16:00Z

Which of these statements resonates most with you?

"Management wants a reporting dashboard."

"The client needs a reporting solution with the app we just delivered."

"You can’t manage what you don’t measure."

Reporting against data is a natural extension of just about any application. Beyond that, typical business environments are replete with data warehouses, SharePoint installs, web services and other data structures with data eagerly awaiting analysis.

Usually reports are coded from the ground up because stock reporting solutions just don’t suffice. The needs of each organization are unique to the business and often require some finesse. Unfortunately this “finesse” comes at the cost of more code to write and maintain, more licenses for reporting development and server environments, more work for IT support staff - and the list goes on.

Wouldn’t it be great if you could just connect to these data services and build reports that make sense on something as easy-to-use as your iPad?

Yes, indeed - meet ReportPlus!

ReportPlus is a self-service business intelligence tool which makes it easy for you to connect to enterprise data sources and quickly get started. Using nothing but standard gestures and interactions you can build reports all on the iPad. Now when I say enterprise data sources that means data as formally structured as SQL Server Reporting Services to data thrown together in an Excel sheet – it’s just that flexible.

Building Reports

Once you’ve chosen a data source then you can easily build pivot tables, sort and filter your data and select a visualization style.

You have complete control over the fields that show up in your report. You can even drag and drop items in the Fields list to reorder the fields in the report.

The pivot editor gives you the ability to slice-and-dice data in ways that make the most sense to you. You can even add ad-hoc filtering by dragging fields into the Filters placeholder.

Once the data is shaped the way you want it then you select a visualization type. There are a host of visualization options that range from single and multi-series charts, maps and text.

Then you can fine-tune the final result by adding conditional filters, configuring the data fields or decide on the final look of the visualization.

Once the dashboard is complete you can choose to share either with other ReportPlus users or anyone with an email address. Existing ReportPlus users can have access to the source dashboard file and those without an iPad or ReportPlus can access either screenshots or PowerPoint presentations sent directly to their inbox.

For more details and quick overview, check out the ReportPlus introduction video.

So, for me, ReportPlus is really exciting because now the tedious task of building reports is just as simple as tapping away at your iPad. ReportPlus is available in the App Store here.

Full Disclosure: Yes, I am the voice of the ReportPlus videos, but I am also a developer and I truly would rather do reporting the ReportPlus way rather than build them from scratch ;)

Avoiding Remote Desktop Connection Error: Console Session in Progress

2012-08-21T13:33:00Z

I've recently ran into run into a remote desktop connection error where the error message:

Your computer could not connect to another console session on the remote computer because you already have a console session in progress.

...doesn't exactly do justice as to what was really happening. I detail the workaround here.

2 Step Process to Upgrade Windows 8 JavaScript Applications from RC to RTM

2012-08-17T18:30:00Z

Now that Windows 8 and Visual Studio 2012 are in their final state you may have a number of Windows 8 JavaScript projects built with the RC of Visual Studio 2012 that now need an upgrade to RTM bits. The upgrade process is simple: update the WinJS project reference and update the markup.

Update the WinJS Reference

The Windows 8 JavaScript project template includes a reference to WinJS by default. When you open a project build with the RC in the final version of Visual Studio you’ll see a broken reference.

To update the reference to RTM, delete the broken reference, open the Add Reference dialog and select the Windows Library for JavaScript 1.0 Windows Extension.

Update the Markup

HTML pages that accompany Windows 8 JavaScript applications include references to style sheets and JavaScript files that are embedded in WinJS itself. The RC markup includes a suffix of ".RC" in the HTML markup referencing these resources:

To upgrade the markup do a Search and Replace (throughout the entire solution) replacing Microsoft.WinJS.1.0.RC with Microsoft.WinJS.1.0

You’re all Done!

Now just run your app to test and ensure everything else works as expected.

Note: There may be some cases where other adjustments may be necessary if any API changes occurred between RC and RTM, these steps should your old projects at least running in the final environment.

3 Essential Tips for ASP.NET Developers Moving to WinJS / Metro Application Development

2012-05-14T21:41:00Z

One of the most exciting announcements surrounding Windows 8 development is the fact that you can create Metro-style applications in HTML 5 and JavaScript. This means that you as a web developer can leverage your existing skills and tools and to develop Windows applications.

However, moving from traditional web development to WinJS (a.k.a. Metro-style or Windows 8 applications) development can be a bit of an adjustment if you are an ASP.NET developer by trade. Therefore here are a few tips to help you keep your head on straight as you make your way into WinJS development.

tl;dr

You can take your existing skills as a web developer and apply them to WinJS, but not everything transfers and you’ll have to fill in some gaps.
Grasping the inherent difference between stateless and stateful applications and learning the new UI framework is at the core of a successful switch from ASP.NET to WinRT applications.

1: There is No Server

As web developers we are used to stateless client-server architecture of our applications. We are used to the concept of a distinction between server-side code and markup. We’re used to the constraints of session, view state and have adapted to the benefits of Ajax to help increase the effectiveness and responsiveness of our applications. It might seem like I am stating the obvious because WinRT development after all is Windows development by definition, but when you use web technologies (that you've grown accustomed to using for the last decade or so) without the existence of a server - it can be a bit of a paradigm shift without a clutch. Further, web servers are expected to be more or less reliable and available. A Windows 8 application can be suspended, resumed or even terminated with very little ceremony.

Practical Implications

Classic stateless challenges disappear
Classic stateful challenges appear (For instance, once you load a CSS file into a page it doesn’t go away just because you navigate to a new page. This could cause problems if you’re not careful.)

2: No Generated Markup

While working with a binding template that wasn’t rendering correctly, I opened the Visual Studio DOM Explorer looking for a value I had applied to an element's class property. The value didn’t get applied because I tried to apply it directly to the class property (which is exactly what you would do if you were working with a server control). Looking back on this face-palm moment I realized that it should have been obvious to me that a JavaScript binding was at play instead of my normal thinking of “generated HTML by the server”. Instead of setting the class property I needed to set the className property as className is the valid JavaScript notation to set the class property of an element.

Practical Implications

WinJS applications use JavaScript exclusively to manipulate the view – all the same rules apply
Technically markup is generated in the view, but it’s not generated into the markup stream. New elements are generated in-memory by JavaScript when you are dynamically manipulating the DOM.

3. There is a Learning Curve

Remember how we said you could write Windows 8 applications with HTML and JavaScript? Well that’s all true, but that doesn't mean that the same .NET framework APIs you’re used to are available. For instance: Want to send an email? Go for it, but you won’t be using System.Net.Mail to make it happen. Have an existing business logic layer that you want to expose to a Metro app? Well, you’ll need to create a WinMD wrapper or expose it via an xhr request. If you are directly referencing managed code, you must make sure you only expose Windows Runtime Types as return types and parameters in your methods.

Further, the WinRT framework comes with a host of new controls, animations and design considerations that were never at play in the past. For instance you may be a wizard at jQuery UI, but those same controls may not present as well in a Metro application as they do in a web application.

Practical Implications

Working with managed code in WinRT is similar to, but not the same as writing the run-of-the-mill .NET application
There are new design considerations and UI patterns to learn and apply appropriately

4. It’s a ‘State’ of Mind (Bonus!)

As I’ve alluded to above, a big part of making the switch is fully grasping stateful application development. Let me give you an example. ASP.NET developers are used to a page event lifecycle where a request comes into the page which is usually first handled by Page_Load then control event handlers fire then you have a final chance to interact with the page at Pre_Render and then you’re done. Many of these events are indicative of the statelessness of a web page. In a Metro application you’ll handle the activation event (roughly equivalent to the jQuery ready event) , the suspended event and the restored event (which coincidentally are indicative of the statefulness of a native application).

Practical Implications

The stateful nature of a native application means that you will interact with controls and data in a different way than you would in an ASP.NET application. Issues like guarding against global variable pollution in JavaScript and allowing your application to gracefully handle being suspended, resumed or terminated become an important part of your development concerns.

What Do You Think?

What other aspects of the transition would you include in this list?