Search results matching tags 'Infragistics', 'CDN', and 'Hierarchical'

How to get started with jQuery Grid Unbound Columns

dpetev — Tue, 16 Oct 2012 14:26:00 GMT

An all new functionality with the second release for this year comes to bring more flexibility to your grid and the way it handles data. The unbound column is one of the classic grid features throughout Infragistics experience with grids and now user demands are met by the all-new-yet-same Ignite UI Grid :)

The feature itself allows for columns that can be used to render separate arbitrary list of items or calculated values usually based on other columns’ values. The columns support and work with all grid features – proper sorting, filtering, etc. Also normal column enhancements like column templates, formatters and any other column property are available. It is very simple in concept and then once you get a closer look and take into account how this would interact with features it can get quite complicated, but that would be something to dive into later on.

Why Unbound columns?

What good are they for? For one, imagine a situation I end up in quite often – I like using Entity Framework but when I reach to the part where data needs to be send to the client all hell breaks loose. Why on earth has this not been addressed is beyond me but the Entity objects are damn near impossible for the default serializers and this has been around for so long. So what you do is either go for third party ones or use Data Transfer objects that are meant for such cases and that works good for me most of the time and it reduces traffic too. In those cases when one data model is not enough and out of you control, for when you need data from different sources and the Mashup Data Source is too much hassle or you don’t even have some parts available when the grid is created… this is when an unbound column can totally save the day.

Then again that is not all – besides integrating two pieces of data, the unbound columns can be used to display completely new data. You can use the formula property to calculate values based on other values in the row. That means you can now create Summaries on per row basis, rather than the out-of-the-box ones for columns!

Quick setup

At first glance the unbound columns are no harder to define that any other - as mentioned, all properties are available and features behave as expected. The single most important difference is the ‘unbound’ property that you can set to true in order for that particular column to be omitted when binding to the data source. Essentially you can get an empty column with no relation to the data model:

 columns : [{
        unbound : true,
        key : 'empty',
        headerText : 'Empty',
        dataType : 'number'
    }
],
 

To put things in perspective, here’s the full grid definition.

 $('#grid1').igGrid({
    width: '650px',
    autoGenerateColumns : false,
    autoGenerateLayouts : false,        
    columns : [{
            key : 'BusinessEntityID',
            dataType : 'number',
            headerText : 'B.E. Id'
        }, {
            key : 'SickLeaveHours',
            dataType : 'number',
            headerText : 'Sick Leave Hours'
        }, {
            key : 'VacationHours',
            dataType : 'number',
            headerText : 'Vacation Hours'
        }, {
            unbound : true,
            key : 'empty',
            headerText : 'Empty',
            dataType : 'number'
        }
    ],
    features : [{
            recordCountKey : 'TotalRecordsCount',
            pageIndexUrlKey : 'page',
            pageSizeUrlKey : 'pageSize',
            name : 'Paging',
            type : 'local'
        }, {
            sortUrlKey : 'sort',
            sortUrlKeyAscValue : 'asc',
            sortUrlKeyDescValue : 'desc',
            name : 'Sorting',
            type : 'local'
        }, {
            filterExprUrlKey : 'filter',
            filterLogicUrlKey : 'filterLogic',
            name : 'Filtering',
            type : 'local'
        }
    ],
    height : '600px',
    dataSource : "@Url.Action("Employees")",
    responseDataKey : 'd'
});
 

And the result of this is:

As you can see you get a column of whatever type you have defined and the filter criteria match that too.

ASP.NET MVC

The helpers provided with the product could always be used instead to help you generate the same output with great ease. You actually have two options when using the server side assembly – chaining syntax with the HTML helper alone or combined with the grid model. Let’s see how that’s done. With just the helper in which case the model passed by the controller is the actual data:

 @using Infragistics.Web.Mvc
@model IQueryable<GridUnboundColumn.Models.EmployeeDTO>
 

 @(Html.Infragistics().Grid(Model).AutoGenerateColumns(false).AutoGenerateLayouts(true)
    .Columns(column =>
    {
        column.For(x => x.BusinessEntityID).HeaderText("B.E. Id").DataType("number");
        column.For(x => x.SickLeaveHours).HeaderText("Sick Leave Hours").DataType("number");
        column.For(x => x.VacationHours).HeaderText("Vacation Hours").DataType("number");
        column.Unbound("empty").HeaderText("Empty").DataType("number");
    })
    .Height("600px")
    .Features(feature => 
        {
            feature.Paging().Type(OpType.Local);
            feature.Sorting().Type(OpType.Local);
            feature.Filtering().Type(OpType.Local);
            feature.GroupBy().Type(OpType.Local);
        })
    .DataBind()
    .Render()
)
 

Or using the grind model where the latter is being passed to the view:

 using Infragistics.Web.Mvc
 

 public ActionResult Demo()
{
    ViewBag.Message = "Below the grid ....";
    AdventureWorksEntities context = new AdventureWorksEntities();
    var employees = context.Employees.ToList().ConvertAll(e => e.ToDTO());
 
    GridModel grid = new GridModel();
    grid.AutoGenerateColumns = false;
    grid.Columns = new List<GridColumn>();
    grid.Columns.Add(new UnboundColumn()
    {
        Key = "empty",
        HeaderText = "Empty",
        DataType = "number"
    });
    grid.Columns.Add(new GridColumn()
    {
        Key = "BusinessEntityID",
        HeaderText = "B.E. Id",
        DataType = "number"
    });
    grid.Columns.Add(new GridColumn()
    {
        Key = "SickLeaveHours",
        HeaderText = "Sick Leave Hours",
        DataType = "number"
    });
 
    grid.Columns.Add(new GridColumn()
    {
        Key = "VacationHours",
        HeaderText = "Vacation Hours",
        DataType = "number"
    });
    grid.DataSource = employees.AsQueryable();
    return View(grid);
}
 

And that is merely consumed in the view:

 @using Infragistics.Web.Mvc
@Html.Infragistics().Grid(Model)
 

Note: While the result will generally be the same, the above grid model is missing feature definitions just for this snippet. Also all snippets so far assume you are aware scripts need to be loaded in advance either manually or using the Infragistics resource loader widget. For full code refer to the demos themselves or general help with proper setup can be found in the Deployment Guide in our online help.

“So now how do I get data in there?”

That’s the logical question that follows. You have a column completely unrelated to your data model but it’s empty and that’s not why it’s there. Rest assured, you are quire in luck when it comes to options to supply values for those type of columns.

Unbound Values

So now comes the part I mentioned with model serialization and DTOs. The simple task of displaying AdventureWorks () Employees that has no names also requires the Person table. For the sake of the example imagine you don’t have access to the model OR those are in separate databases even. So the grid is bound to the ‘Employees’ and since I only want the names from ‘People’ I provide them in a separate list.

ASP.NET MVC

 public ActionResult Mvc()
{
    ViewBag.Message = "Below the grid ....";
    AdventureWorksEntities context = new AdventureWorksEntities();
    var employees = context.Employees.ToList().ConvertAll(e => e.ToDTO());
    ViewBag.people = context.People.Select(p => p.FirstName + " " + p.LastName).ToList();
    return View(employees.AsQueryable());
}
 

Keep in mind the list can be absolutely anything, really from values from remote APIs to calculated or generated values. Next in the view we have same grid definition as above with the addition of using the ‘UnboundValues’ option:

 column.Unbound("name").UnboundValues((ViewBag.people as List<string>).Cast<object>().ToList()).HeaderText("Name").DataType("string");
 

And using the model (you can see the :

 grid.Columns.Add(new UnboundColumn()
{
    Key = "name",
    HeaderText = "Name",
    UnboundValues = context.People.OrderBy(p => p.BusinessEntityID)
        .Select(p => p.FirstName + " " + p.LastName)
        .ToList().Cast<object>().ToList(),
    DataType = "string"
});
 

Of course, those server side properties are proxy to the client API where you can use it like so:

  var peopleNames = @Html.Raw(Json.Encode(ViewBag.people)) ;
 

  {
                unbound : true,
                key : 'name',
                unboundValues : peopleNames,
                headerText : 'Name',
                dataType : 'string'
            },
 

Note: When using the ‘UnboundValues’ property the list of provided values is assigned as is – meaning is the same order, which means that those *must* be ordered the same way as the data source if you want meaningful results.

Set Unbound Values

The very same result can be achieved using the ‘SetUnboundValues’ grid method. With it you can provide values for any columns by specifying its key:

 grid.Columns.Add(new UnboundColumn()
{
    Key = "name",
    HeaderText = "Name",
    DataType = "string"
});
grid.SetUnboundValues("name", peopleNames);
 

The method is also available with chaining and it has two overloads – one accepting as second parameter either a value list like so far or a dictionary with primary key and value pairs. The latter naturally requires your grid to have a primary key defined and if that is the case it is the recommended method to use as it’s the end result of the other overload anyway (yes, by all means, read that as performance gain). This can also spare you the hassle of having to order your sources the same way because using the Dictionary overload you can essentially assign value for each primary key. So for the above ‘peopleNames’ you can now use something like:

 var peopleNames = context.People.ToDictionary(x => (object)x.BusinessEntityID, x => (object)(x.FirstName + " " + x.LastName));
 

NOTE: While the unbound column itself may not support some remote feature (see below), other columns normally would and their results affect the entire data view and for correct results you absolutely need a proper mapping between unbound values and the grid’s primary key, therefore the above Dictionary overload of the ‘SetUnboundValues’ method is always the best option to be used.

As always things in client-side script are much less constrained and also somewhat different in functionality as it’s executed after the control is initialized. You can do that either in grid events or user triggered actions. For a start the easiest way is to go for a button click:

 <button onclick="$('#Grid1').igGrid('setUnboundValues', [ 'John Doe(1)' , 'John Doe(2)' , 'Jane Doe(1)', 'John Doe(3)'], 'name')"> Set Unbound values </button>
 

Note: The client version of the method as you can see takes values first and then the key and can be called after the grid is initialized regardless of the unbound column state – be it still empty or already initialized with values, so this can be combined with the previous resulting in a prefilled on the server column and just the first few values replaced by the method:

Formula

The probably most exciting part. It’s not really even a formula per se. It’s a JavaScript function that is called with the rest of the row data and reference to the grid so it can calculate and return a value for the unbound column. However, since it’s just a client function you can return pretty much anything and obtain it in any way. That is powerful. Here’s the most basic usage I mentioned making some kind of row summary if you will. Inside the grid column definitions:

  {
                unbound : true,
                key : 'total',
                headerText : 'Total',
                dataType : 'number',
                formula : calcTotal
            }
 

 function calcTotal(row, grid) {
    return row.SickLeaveHours + row.VacationHours;
};
 

Note that the row is pretty much the current data record even with the ‘name’ unbound value we already have. Also the formula property can be set with string, which I’m sure you will see when using the identical MVC property:

 grid.Columns.Add(new UnboundColumn()
{
    Key = "total",
    HeaderText = "Total",
    DataType = "number",
    Formula = "calcTotal"
});
 

The result of this is the heading screenshot of course.

Gotcha-s

As I explained it’s a deceptively simple feature and once you look into it it’s quite something. That warrants a few limitations. While it does work just fine on the client with every feature, the server side compatibility is lacking – in fact, remote Filtering, Sorting and GroupBy are not supported for unbound columns. You could potentially perform updating but as you can imagine the rows (grid records) no longer match the server model the grid was bound to so custom deserialization would be required.

There’s also the matter of how the additional data is to be handled and that is dictated by the ‘mergeUnboundColumns’ property. There are some performance implications to this that we’ll leave for some other time (read: the second blog, find directs links to skip to that below).

Resources and demos

How to configure jQuery Grid Unbound Column and make the most of it
- Using unbound columns with advanced column options such as Templating or formatting.

You can instantly try the the feature with this JSFiddle demonstrating different ways to set unbound values.
A shared demo for this and the previous blog – and ASP.NET MVC project with various grid configurations described so far. Keep in mind most views use the MVC wrapper and require at least a trial version of Ignite UI on your machine – click the banner below to get yourself one.
There are two demos available in our Samples: Unbound Column in the Grid and Unbound Column in the Hierarchical Grid.
You can find general and control specific help in our Online Documentation
You can find the client-side options and methods in the Ignite UI jQuery Grid API reference.

As always, you can follow us on Twitter @DamyanPetev and @Infragistics and stay in touch on Facebook, Google+ and LinkedIn!

TL;DR | Summary

We’ve looked into the benefits and different applications of the all new Unbound Columns feature in the Ignite UI jQuery Grid. We’ve went through adding such a column to the grid and the different ways to provide it with data in both client-side scripts and using the ASP.NET MVC server-side helper/wrapper. We noted some cases to in mind and in a following blog we’ll go into greater detail about the ‘mergeUnboundColumns’ property and also methods to get values from unbound columns.

jQuery Mobile Controls by Infragistics

dpetev — Fri, 18 May 2012 14:33:00 GMT

With the jQuery product Infragistics envisioned business intelligence and data visualization across a range of platforms, not just one – more like every single one of them. Built on popular and largely supported HTML5 and jQuery UI and striving to provide a comprehensive toolset for development of performant and stylish applications that are to run on every device regardless of the OS. On top of that ‘mobile' was a subtle, yet dominant theme across our product line with the latest release. Touch support and metro themes everywhere! But there’s more to it – the jQuery UI is awesome and will run on just about any modern browser, yet it was not specifically designed for mobile devices, not until recently anyway! jQuery’s Mobile framework is- still relatively fresh, but it is just what you might need – it’s touch optimized, it’s compatible with with most smartphones and tablets and other frameworks(like PhoneGap). It is designed to be lightweight and its UI controls designed for pocket-size pages and touch, but it’s not limited to that, as mobile pages will scale to the screen so it would work and look just as good on a bigger tablet and even a desktop(check out their demos using nothing but the framework). As with JQuery UI, it’s a strong cross-platform solution with a different perspective but the same goal – beautiful, powerful, universal solutions to your app problems. It sounds too good to miss, right? We thought so too…

Enter the Infragistics jQuery Mobile controls

With this release besides all controls taking on a touch-friendly nature, our NetAdvantage for jQuery family grew with specialized mobile controls leveraging the jQuery Mobile framework – the Mobile List View and a mobile version of the Rating. As explained, with them the focus is on mobile-centric and gesture-friendly UI. That means optimizations for mobile devices for stuff like better content placement and some specific interactions along with touch support – larger UI elements to interact with and specialized events like tap hold, swipes, etc.

The List view

Sometimes for small screen devices like smartphone a full-fledged grid control would be somewhat hard to imagine and hardly optimal in terms of productivity. It’s why mobile design, while trying to fit as much functionality in a limited space as possible, must not clutter or expect to fit everything in one page. This is why the mobile framework provides AJAX based navigation between pages (and by pages I mean their mobile version and multiples can very well exist in one html file). This is also where a control such as the list comes in play – think of it as the mobile version of the grid type control – it fits the environment well, it’s easy to interact with, it can hold a lot of data and it can be hierarchical! The igListView is a widget that implements a hierarchical (nested) mobile list. Defining can be done in both in the well-known JavaScript/jQuery or using our ASP.NET (MVC) helpers. There’s also a third method that is also the default method for the mobile framework – a pure markup definition that also has some plus sides. Settings are made via the HTML “data-*” attributes that are mostly for data storage and ignored by browsers when interpreting UI. So for a list you can simple define the standard UL and LI elements and if for some reason jQuery scripts fail to load or execute the browser would still have valid UI to render.

Now that approach wouldn’t be very appropriate if you need some serious amount of data and the Infragistics Mobile ListView comes with a major data support enhancements, one of which is templating. That means not just controlling the markup of each record but also defining a single UL-LI element and point the widget to data and it will template it appropriately. The other major additions to data handling:

Search filtering with the added option of presets
Using the Infragistics Data Source means the controls can bind to a variety of sources
Sorting, sorting presets and groups separated with list deviders.
Load on Demand capabilities

The Rating

The mobile version of the rating control designed for touch means accuracy levels are restricted to whole numbers (or alternatively rounded to halves when the control is in read-only mode). The widget offers settings to control its layout along with getting and setting value, vote count and a changed value event along with the framework’s touch-oriented ones. And as expected you can always tweak the items the rating is using to some other shape or color.

Style

As you can tell by the screenshots above we’ve designed a beautiful iOS style theme for our mobile controls. And for any of you familiar with jQuery UI you’d expect a common and powerful themeing framework to be in play for mobile as well – and there is! Our theme will style all default UI components as well and it can be replaced with one of your own. And yes, there’s a ThemeRoller for jQuery Mobile! It’s very easy to use – all mobile themes have 3 swatches that are usually used for default layouts and actions. Just like that our iOS theme has 3 swatches – a light C (default) swatch seen above with the list, darker B and the A swatch (the one with the exquisite fabric background above). I’ve made a theme myself for what was like 10 min in a metro-style attempt and I’ve included it in the demo just in case someone likes it:

A Mobile App

Let’s see how easy it can be to create a mobile app that is functional and stylish. We’ll stay on the wave of new technology for the demo and create this app using the new mobile template in ASP.NET MVC 4! What would that do is it would lay all the basic layout of the app for you – referencing all jQuery scripts (mobile included) and styles, bundling and minifying them. It would also render your Views in the mobile version of a page by marking the content DIV with data-role="page". So all left to do is add the Infragistics Mobile Loader ask for the control you need and define it. For this demo I’ll use Northwind again with two actions in the controller returning JSON serialized parts of it for an somewhat odd-styled manual load on demand scenario for the details of each list item (again this is different from the load on demand feature the igListView has which allows the end-user to request another portion of data to be loaded for his current list). Here’s the snippet for the list:

<script>
    $.ig.loader({
        scriptPath: "../../Scripts/Infragistics-mobile/js/",
        cssPath: "../../Content/Infragistics-mobile/css/",
        resources: "igmList.Filtering.Sorting",
        theme: "@ViewBag.Theme"
    });
 
</script>
 
<ul id="actionFedList"
    data-role="iglistview"
 
    data-auto-generate-layouts="false"
    data-data-source="/Home/Customers"
    data-bindings-header-key="ContactName" 
    data-bindings-primary-key="CustomerID" 
    data-bindings-text-key="Country"
 
    data-auto-generate-layouts="false"
    data-initial-data-bind-depth="0"
    data-bindings-details-title-key="CustomerID"
 
    data-sorting="true"
    data-sorting-type="local"
    data-sorting-auto-generate-sort-presets="false" 
    data-sorting-presets='[ {"text":"Customer ID","sortedFields":[ {"fieldName":"CustomerID","direction":"asc"} ]}, {"text":"Contact Name","sortedFields":[ {"fieldName":"ContactName","direction":"asc"} ]}, {"text":"Country","showGrouping":"true","sortedFields":[ {"fieldName":"Country","direction":"asc"} ]} ]'
    
    data-filtering="true"
    data-filtering-type="local"
    data-filtering-search-bar-field-name="ContactName,Country">
    <li>              
                    <ul data-role="childLayout"
 
                        data-auto-generate-layouts="false"
                        data-data-source="/Home/Orders"
                        data-bindings='{"customerId":"CustomerID"}'
                        data-inset="true"
                        data-generate-compact-jsonresponse="false"
                        data-bindings-count-key="Freight"
                        data-key="CustomerID"
                        data-bindings-header-key="OrderID" 
                        data-bindings-text-key="ShipName"
                        >
                    </ul>
                </li>          
</ul>

Note i have my theme set using the MVC dynamic ViewBag and I choose (and let users choose) a theme and call the controller action with that theme. Since I can’t put comments I’ve grouped code to be easier to see which part does what. The magic combo here is data-role="iglistview”. Also note the data source can be a link (it’s the igDataSource after all) so local JSON, actions results, services, XML, oData and so on – check! Defining header and text key are the properties in your data to be displayed for each record, the initial bind depth set to 0 will let the list know we have provided just the data for the main list (otherwise the list will ignore those layouts since child data is not loaded). Sorting and filtering are truly easy to enable with just a property and you can also customize them with presets and in them setting "showGrouping":"true causes the list to group the sorted results just like the screeenshots above. And yes you can define custom sorting functions and group comparers if you so desire, but for our basic demo there’s no need. In the child layout we again set the source to a actiong link and the data-bindings='{"customerId":"CustomerID"}' property instructs the list to include this as part of the links query so we can send the data for the right customer and the result:

This sub-page is all auto-generated for you, navigated to using AJAX, back button and history maintained!

Adding the rating is just as easy, again either through markup, helpers or initializing with script. Also as we mentioned you have the ability to now develop against specialized touch events so you can provide that little extra interaction to mobile users – we would use the long tap gesture to reset the rating and also handle the changed event:

@using Infragistics.Web.Mvc
 
<script>
    //load the resources:
    $.ig.loader({
        scriptPath: "../../Scripts/Infragistics-mobile/js/",
        cssPath: "../../Content/Infragistics-mobile/css/",
        resources: "igmRating"
    });
    // show the changed value
    $(document).delegate("#rating", "igratingvaluechange", function (evt, ui) {
        var voteCount = $(".selector").igRating("option", "voteCount");
        $("#ratingValue").text("Rated: " + ui.value + " star(s)!");
    });
    // reset the rating on tap hol
    $(document).bind("#rating", "taphold", function (evt, ui) {
        if (!Modernizr.touch) {
            return false;
        }
        $("#rating").igRating("value", 0);
    }); 
</script>
<h2>
some rating</h2>
<P> Tap to set value, tap and hold to reset (zero). </P>
<!-- Markup defined -->
<div id="rating" data-role="igrating" data-value="3">
</div>
 
<p id="ratingValue"></p>
 
<p> Read-only Rating defined with the MVC helper:</p>
  @(Html.InfragisticsMobile().Rating()
        .Value(4)
        .ReadOnly(true)
        .Render()
)

You can get and set rating’s value and vote count at all times and the changed event offers both the new and old values along with regular references to owner and so on. Read-only mode rating converts to a smaller form (no longer need to be big enough to be touched):

And, lastly, you can always override the default images or their locations to change the appearance of the control to match your theme. Below I’ve change the non-iOS default stars for the rating form yellow to blue to match my theme’s looks:

Wrapping Up

If you want to build a mobile friendly app the jQuery Mobile framework is an excellent choice and we are offering that extra functionality for you to take advantage of – hierarchical list with templating, advanced filtering, sorting, grouping and impressive load on demand features and support for a wide array of data sources and a beautiful mobile rating optimized for touch interactions to truly score you those five stars! And there’s a bonus – everything is optimized for mobile devices, but it looks and works perfectly good on a desktop as well!

I strongly recommend to take a closer look into jQuery Mobile and check out our awesome samples (there are codes in there for you to scan and try them on you mobile device too!). Also you can download a fully functional unlimited trial of NetAdvantage for jQuery and the Demo Project for this Blog – an APS.NET MVC 4 mobile application you’ve seen bits from above and should definitely try!

Follow us on Twitter @DamyanPetev and @Infragistics and join the competition on Facebook!

jQuery Hierarchical Grid - Load On Demand

dpetev — Wed, 15 Feb 2012 13:00:00 GMT

The Hierarchical Grid (a fairly recent addition to our NetAdvatage for jQuery) is a client-side control that can display hierarchical ( or nested data if you will, the kind of stuff you would use an Org chart or a tree of some sorts to visualize). Now while in some cases other controls just may do, when presented with large amount of information and it requires a table-like representation then the igHierarchicalGrid should definitely be your go-to control. Using a hierarchical grid representation is a amazing reduction in terms of space required per data unit as it allows for not only child layouts to be collapsed and expanded but also provides paging and all the things you’d expect from a grid. And while this is all great, it kind of makes you wonder where else you can save up some. There is, in fact, a very obvious route to take – collapsing and expanding layouts sounds like a great target – why have them while they are not visible? That is indeed the right question. You can say we have thought about that as such way of thinking is in the very design of the control – the hierarchical grid is relying on the flat igGrid control to display child layouts and it creates an instance only when a row is actually expanded. What this means is that all the markup (HTML elements) that might represent a 50 rows worth of child entries would not be created and sit around until and if the user decides to expand their parent row. This reduces the total resources required and at the end of the day it equals performance boost. “Good!”, you might say, yet there is .. more! The Hierarchical Grid is already taking care of its child UI elements for you, but what about the data? Of course that essential side has not been forgotten and the igHierarchicalGrid comes with a ‘Load On Demand’ support. What this brings is the ability to load data only when it is required making that control that much more lightweight and while enabling it, you also lay the foundations for some other nifty features such a remote paging, filtering and sorting. You are, however, required to give it a little push, so keep reading to see how to do just that!

Also here’s and inspirational screenshot of that all-time favourite spinning indicator users would and should see when they must be informed something in the background is happening and that is pretty much the only indication something like Load On Demand is active. Keep in mind this took several attempts to nail the split-second the indicator is visible, so bear with me on its aesthetics :)

Load on Demand with jQuery

Now if you’ve been examining the jQuery API of the Hierarchical Grid you might be wondering where is that ‘loadOnDemand’ property? Simply put, the jQuery widget doesn’t really have one. To be completely thorough… the ASP.NET MVC helper does have one (as it sets up some behind-the-scenes server magic) but more on that later on. The widget doesn’t need that as it is a client control completely independent from server technology and as such in no way does it implement loading data on demand, but rather it should be made aware of such opportunity and if the proper setting are in place the grid will take advantage of it. With that said, the control can consume OData (Open Data Protocol) and with the very nature of the protocol that spells querying data (including paging, ordering and filtering) what follows seems completely natural – when presented with OData the grid will use it to request data only when needed – yes, loading it demand. That means that if you have your information exposed with OData protocol you are almost ready! All that is left to do to get the feature is three properties:

 $("#hierarchicalGrid").igHierarchicalGrid({
 
    //--Set up for Load on demand follows:
    odata: true,
    initialDataBindDepth: 0,
    dataSource: oDataInJson,
    responseDataKey: 'd',
    //--end--
 
    autoGenerateColumns: true,
    primaryKey: "ID",
    columnLayouts: [
        {
            name: "Products",
            responseDataKey: 'd',
            childrenDataProperty: "Products",
            autoGenerateColumns: true,
            primaryKey: "ID"
        }
    ],
    width: "700px",
});
 

As seen in lines 4 through 7 there isn’t all too much complication about it – make the grid aware OData will be used (setting the respective property to ‘true’) and provide a source.

The initial data bind depth is obligatory and it tells the grid just how much in the nested data structure should it dig right from the start and while usually that means setting it to as many levels your data has or even –1 for the “I don’t know! Can’t you just figure it out and load everything?” case, when the goal is loading on demand you want that to be zero – as in just the first(parent) tier of entries will be loaded.

The response key is telling the grid how to look at your data and is specific to it as well. It is only needed when that data is wrapped and it points to where the array of records is. Let’s have a more descriptive example – as seen above is is set to ‘d’ and that is because in that demo the sample OData service response looks like..

?({

"d" : [

{

"__metadata": {

"uri": "http://services.odata.org/OData/OData.svc/Categories(0)", "type": "ODataDemo.Category"

}, "ID": 0, "Name": "Food", "Products": {

//rest is omitted

Now take the NorthWind sample service for example:

?({

"d" : {

"results": [

{

"__metadata": {

"uri": "http://services.odata.org/Northwind/Northwind.svc/Customers('ALFKI')", "type": "NorthwindModel.Customer"

}, "CustomerID": "ALFKI", "CompanyName": "Alfreds Futterkiste", "ContactName": "Maria Anders", "ContactTitle": "Sales Representative", "Address": "Obere Str. 57", "City": "Berlin", "Region": null, "PostalCode": "12209", "Country": "Germany", "Phone": "030-0074321", "Fax": "030-0076545", "Orders": {

//rest is omitted

In this case the response key would be “d.results”. Simple enough and again specific to how you present your data.

In the light of all this you can check out Taz’s blog on Using OData with jQuery Hierarchical Grid where you can find not only a full guide but also a link to a live demo!

If you take a look at the example in that blog you might notice the datasource is set to the service URL. This is because the grid itself will use a igDataSource control to bind to data and as such it is available for you as well. If you want to tweak some of its setting you can define your data source like so:

var oDataInJson = new $.ig.JSONPDataSource(
    { dataSource: 'http://services.odata.org/OData/OData.svc/Categories?$format=json&$callback=?', 
    responseDataKey: "d" 
    });

You can read more about this control in our Help Topics.

Load On Demand with ASP.NET MVC

Unlike the majority of our jQuery products where the helpers mostly mirror the widget’s settings and add some comforts for those used to writing in a managed environment, this time it’s different. As said above the igHierarchicalGrid MVC wrapper does have a Load On Demand property. When that is set to true the wrapper provides utility to send responses to the client in JSON format. To be more specific it is the grid’s model that provides the support for that. There’s a catch though – the responses use the model’s GetData() method and that means the model is needed wherever those responses are created, which makes setting up the grid in the View with chaining syntax something you might want to avoid. The model of the grid along with all the properties should be then defined in either the Controller of the Model. There is also one more thing to note – the model creating is best done in a separate method and here’s the full code for one:

using Infragistics.Web.Mvc;

private GridModel CreateGridModel()
{
    GridModel grid = new GridModel();
 
    // Set up properties and columns:
    grid.AutoGenerateColumns = false;
    grid.Columns = new List<GridColumn>();
    grid.Columns.Add(new GridColumn("Customer", "CustomerID", "string", "300px"));
    grid.Columns.Add(new GridColumn("Company Name", "CompanyName", "string", "150px"));
    grid.Columns.Add(new GridColumn("Country", "Country", "string", "150px"));
 
    grid.PrimaryKey = "CustomerID";
    grid.AutoGenerateLayouts = false;
 
    // Create child layout
    GridColumnLayoutModel layout = new GridColumnLayoutModel();
    layout.Key = "Orders";
    layout.ForeignKey = "CustomerID";
    layout.PrimaryKey = "OrderID";
    layout.AutoGenerateColumns = false;
 
    layout.Columns = new List<GridColumn>();
    layout.Columns.Add(new GridColumn("Order ID", "OrderID", "number", "100px"));
    layout.Columns.Add(new GridColumn("Customer", "CustomerID", "string", "100px"));
    layout.Columns.Add(new GridColumn("Order Date", "OrderDate", "date", "150px"));
    layout.Columns.Add(new GridColumn("Shipped Date", "ShippedDate", "date", "150px"));
 
    // Add paging to child layouts (different from the parent's)
    GridPaging layoutPaging = new GridPaging();
    layoutPaging.VisiblePageCount = 2;
    layoutPaging.PageSize = 5;
    layoutPaging.Type = OpType.Remote;
    layout.Features.Add(layoutPaging);
 
    //add that layout to the grid
    grid.ColumnLayouts.Add(layout);
 
    //most importantly turn Load On demand on and define response Urls:
    grid.LoadOnDemand = true;
    grid.DataSourceUrl = this.Url.Action("BindParent");
    grid.ColumnLayouts[0].DataSourceUrl = this.Url.Action("BindChild");
 
    //Also add paging to the parent layout
    GridPaging paging = new GridPaging();
    paging.VisiblePageCount = 2;
    paging.PageSize = 10;
    paging.Type = OpType.Remote;
    grid.Features.Add(paging);
    
    // Return the finished model
    return grid;
}

You will have to scroll down a bit to get to the part we are interested in – starting at line 39 where the LoadOnDemand property is set to true. The layouts had to be created before that so data source URL-s can now be assigned to them.

Now back to the subject of JSON responses as seen above we have defined a grid model with two levels of hierarchy – a parent entries with child entries. Therefore we have the “BindParent” and “BindChild” as seen above. A very important note to take is that such a response is required for each layout, so one method returning requested data for each level in your data. As mentioned those methods would use the model’s GetData(), this is why we moved its creation to a separate method, because it is used to pass the model to the view and in all of those methods as well. Their return type should be JsonResult as that is what the grid would expect, but you don’t have to worry about converting data yourself. This is how those look:

public JsonResult BindParent()
{
    //create a model
    GridModel grid = CreateGridModel();
    //set its datasource
    var dataContext = new NorthwindDataContext();
    var dataSource = dataContext.Customers;
    grid.DataSource = dataSource.Take(30);
    //and use the GetData() method to return the results
    return grid.GetData();
}

And then you have the one for the child layout:

public JsonResult BindChild(string path, string layout)
{
    //create a model
    GridModel grid = CreateGridModel();
    //set its datasource
    var dataContext = new NorthwindDataContext();
    var dataSource = dataContext.Orders;
    grid.DataSource = dataSource;
    //and use the GetData() method to return the results
    return grid.GetData(path, layout);
}

Notice we never defined data source in the model creation method and also notice the response methods set that to the proper table for each layout. Notice as well that the parent requires no parameters – this is based on the way the grid performs internal requests. Parameters guide the method on which layout should the data be set and also its path in the hierarchy. The general path format would describe the sequence in which rows were expanded like so:

PrimaryKeyID/ChildPrimaryKeyID/AnotherChildKey[layout name].

Based on how your grid/data is set up any of the expanded rows’ keys in the path can go with a layout name if it is specific to it. In the case above that would mean the PrimaryKeyID would be the guide for the children under that specific row in the parent, then from them the children of the ChildPrimaryKeyID row and then the specific child layout under AnotherChildKey from the latter. This might seem somewhat confusing but take it like this – it is true to its name – you start from the root (notice it is not mentioned in the path) move down the keys following the hierarchy to get to required data. Now the path above is for 4 levels of hierarchy and since the example so far is just two we only get the first part in the path – the PrimaryKeyID which would be the id of the expanded parent row and look like:

And as you may have already guessed an request with empty path would mean the parent level, thus the BindParent takes zero arguments.

Events

The jQuery Hierarchical Grid offers two events related to Load On Demand. You can start by reading a blog written by Jordan Tsankov on just that – Handling Events in the igHierarchicalGrid. The basic principals on using the LoadOnDemand events is just the same as using rowExpanding or rowCollapsed you can see in that blog. The widget will fire two events consequently upon loading requested data – first ‘childrenPopulating’ and then the standard ‘childrenPopulated’. As always the ‘-ing’ even fires as child layout is just about to be populated with data and is cancellable, while the other event is fired after the population is complete and is not cancellable. Following the convention you can hook up an event handler by just using the name of the control plus the name of the event without further complications like so:

$("#hierarchicalGrid").live("ighierarchicalgridchildrenpopulating", function (evt, args) {
    //you can decline loading data for certain rows, like some that may not even have child items
     //calcel out if calling row with key ID of 0
    if (args.id == "ID:0")
        {return false;}
    //define you own logic to hanle the event
});

As you can find in our API and in Jordan’s blog above you have access to plenty of information about the event and the participants and for the sake of keeping it simple the example above just uses the special ID formed by the row’s primary key and its value to check if the event has been fired while activating load on demand from the very first row. The demo for this project includes event logging for both MVC and OData implementations, so you can check that one out.

The Added benefits

If you remember from the introduction enabling load on demand would also lay foundations for other remote functionalities. You probably have figured it out the moment OData was mentioned – the protocol providers support those features and the grid will make the appropriate requests when remote paging, filtering, sorting and even summaries!

Then there is even more! The MVC wrapper being witty and all will not only parse and execute hierarchical data requests. It is also capable of querying data based on other options it recognizes in the grid’s request – which means that you simply instruct the grid to perform remote those actions and it will create the appropriate requests and the getData() method will return the correct rows. It really is that simple, you define options, set them to remote and don’t even bother setting up URL key(s) for filtering or sorting like you are normally required to. Here’s what you can simply add to the CreateModel method from above:

//Add features:
 GridSorting sorting = new GridSorting();
 sorting.Type = OpType.Remote;
 grid.Features.Add(sorting);
 GridPaging paging = new GridPaging();
 paging.PageSize = 10;
 paging.Type = OpType.Remote;
 grid.Features.Add(paging);
 GridFiltering filtering = new GridFiltering();
 filtering.Type = OpType.Remote;
 filtering.Mode = FilterMode.Simple;
 grid.Features.Add(filtering);

Conclusion

The Load on Demand functionality of the NetAdvantage for jQuery Hierarchical Grid will keep it simple and reward with great results. Should you choose to expose your data via the Open Data Protocol (OData), your client-side implementation of the control will readily take advantage of all it can offer and handle the requests for you with little to no extra effort. And if you prefer different approach the wrapper will assist you greatly in enabling such functionality on your server-side as well as once more managing requests and generating proper responses. And while doing that Load On Demand would also become available for a number of features that can be performed remotely such as paging, summaries, sorting and filtering.

A read you might find interesting in our help topics would be the Getting started with igGrid, oData and WCF Data Services guide in our Help Topics which is another way you can consume OData with your grid.

Also head over to our Samples to try it out and you can also download the Demo project accompanying this blog in which you will find implemented ASP.NET MVC using the wrapper and a pure jQuery / JavaScript implementation consuming OData.