Search results matching tags 'MVC' and 'Hierarchical Grid'

jQuery Grids and Responsive Web Design

dpetev — Fri, 12 Apr 2013 18:37:00 GMT

Responsive Web Design has been abuzz for some time now. In case you just now clash with the term, it’s a web design approach aimed at crafting sites to provide an optimal viewing experience across a wide range of devices. Basically, a CSS3 / JavaScript / jQuery powered site that adjusts itself to better suit the screen it’s on, with the added bonus of keeping a single code base. What’s not to like? Well besides it’s often abbreviated ‘RWD’ which outside of the IT fields stands for Rear-wheel drive, so slightly confusing for people into both.. but that’s a minor issue. Other than that, it’s pretty awesome, but also sometimes hard to implement – some elements of a Web app simply don’t handle well squishing into smaller spaces. Complicated enterprise applications might even require quite a bit of extra work – and as you know with Ignite UI we want to help you get the extra work out of the way! And what do heavy business apps use? Grids, of course!

Now, how do you imagine a big table with a few columns and at least a few hundred rows is to fit in portrait mode on tablets and event more so on phones? The limited space calls for some changes and I’m quite excited to tell you your jQuery Grids will soon (and I mean soon – 13.1 is right around the corner) be equipped with the Responsive feature, ready to fit right into your RWD site! Do I hear clapping? Yeah, that’s not some simple data table we are talking about here – a full-fledged, feature-packed jQuery Data Grid and its Hierarchical version – they can do so much you might as well just make a whole app out of them. A responsive app!

Lastly, if you are in for a quick start with the whole toolset and related concepts you can Get Started Learning Ignite UI Today! The more you know, the more exciting this will be.

What can it do for you and what can you do with Responsive!

The main star of the Responsive feature is allowing you to know in what ‘state’ the app is running and define separate grid and column settings for each to make the best of whatever space you have. For example only do a few major columns for a phone view, some more for a tablet:

And the all the extra stuff when you have the space:

The feature allows you to trigger column visibility based on CSS classes – with a slight nod towards those familiar with or already using popular responsive UI frameworks like Twitter Bootstrap. The RWD Grid comes with 3 modes (mode recognizers if you will, we can work on the naming), that are used to match predefined or custom states ( such as ‘phone’, ‘tablet’ and desktop). Mode Recognizers if you will, but we can work on the naming:

Responsive mode – the base
Infragistics mode
Bootstrap mode

The base implementation looks at the window width, but the Infragistics and Bootstrap profiles rely on CSS3 media classes through a set of classes. Actually here is where Bootstrap comes with their set of media queries and specific classes, that many of you should find familiar. It’s not as simple as putting CSS classes on table cells, though! The igGrid is way too complex for that, but the Responsive feature does the next best thing – hiding columns thought the API methods and detecting when to do that using the class on a test element. I actually love this technique, because that’s how you do a ‘matchMedia’ polyfill (because most mobile browsers support media queries, but not 'matchMedia') and I always thought it was super clever workaround. But anyways, the point is that though CSS you can define when columns will be visible and the grid will do the rest for you. I’ll actually just include a shot of the Twitter Bootstrap description that should be clear enough:

Basically what you do is have you classes in CSS - the ones that come with Bootstrap as above, or the ones from Ignite UI CSS that are pretty much the same, but with out usual “ui-“ prefix, so it’s “ui-visible-phone” and so on. Basically, you need the classes in there – if you are using Bootstrap – great, you can reuse, otherwise we will provide you with them. Those classes are assigned in the column settings on the feature (remember, they are for the test element only) and it really is as simple as adding the Responsive feature to your grid with settings similar to this:

features : [{
        name : 'Responsive',
        columnSettings : [{
            columnKey : 'name',
            classes: "ui-visible-phone"
        }]
        //....

Or you can even configure visibility though simple properties that match the mode’s profiles:

// ...
features : [{
        name : 'Responsive',
        {
            columnKey : 'BusinessEntityID',
            configuration: {
                phone: {
                    hidden: true
                }
            }
        }
// ...

A Template for every occasion

So hiding columns is not enough? Well the Responsive feature kindly offers additional configuration options by providing templates for separate modes. You heard me right – you can swap the entire grid template on every mode and in the same configuration as above, where you define state for modes, you can also add column template specific to each mode! So that’s quite something – with templates you can change the look and feel of the entire grid between modes – shift controls templated into cells back to data or the other way around, merge columns and more! Just keep in mind the row templates are final and will override column ones if mixed.

Customizable, we need it to be customizable!

And so we hear – there’s a whole bunch of settings you can change for way the feature works. The sheer fact that the responsive modes can be quite a few – you can use the classes and have the designer decide thought media queries when exactly should the modes be triggered! That in itself sounds like a good foundation to keep design consideration out of the code.

Then you also have the option to create your own modes… for example have one specially targeted at “phablets” or something like this or any custom width and CSS media query you can think of. You can also extend and define your own mode recognizers (profiles) where you can not only define custom modes, but also use custom logic to say when they are active. That means you responsive grid doesn’t need to depend on CSS or not even on window width..it can be anything you see fit!

Eventful

Well, it’s not just automatic column hiding and template switching.. There’s a whole lot more! The numerous events you can react to are simply a powerhouse of a customization point – you can react to mode changes or even to separate columns going away or coming into view – either way at any point you can perform additional work to improve you app’s experience! You can reduce page sizes, group records, filter, sort or anything you deem helpful. You can even use the Responsive feature events as hooks for script-related modifications of your entire page/app – after all it’s already monitoring the state of the device, you might as well make full use of that! As you can imagine there are great many possibilities of what you can do.

Settings

Besides the elaborate per-column configuration and per-mode settings already mentioned, the Responsive feature doesn’t have that much:

A general setting that will ensure the grid will stretch the full 100% of its parent, overriding other settings.
A sensitivity setting defining just how much of a change there should be before the feature would react to changes in window width. Performance implications here obviously.
And finally the option to disable monitoring container resizes as a whole – again some performance gains and pretty much the difference between a responsive and fluid behavior. If you are interested in that sort of stuff check out the info for our conference below.

Power to the user

Trust me when I say I appreciate every effort a developer has made to improve my experience using a site and I get annoyed when I have to scroll left and right to read a single sentence. But then again, I’m also a user who doesn’t like his capabilities being taken away unconditionally. Yes, responsiveness can bring better experience, but only if you don’t take away from important content and functionality without the option to get them back. Basically, I hate when something gets hidden permanently on some mobile device and I can’t find it. It’s infuriating, even more so with RWD where I can’t just skip to the desktop version and make do.

In the case of the Ignite UI Grid that would mean using the Responsive feature to hide columns that might contain required information. There’s usually a reason for that data to be there and simply removing it from the picture just cuts of functionality from the app! Best part is that the Column Hiding feature will provide the UI when Responsive kicks in for free:

This is something I personally can’t see such a feature without. So, in case you are hiding columns, please consider giving the user the option to control what he’s seeing.

Resources

This has been more a general overview of the Ignite UI jQuery Grids’ Responsive feature aimed at Responsive Web Design (RWD) and a kind of a teaser for the upcoming 13.1 goodness. I’ll be making some more blogs with more code, demos and tricks very soon, so stay tuned!

Get Started Learning Ignite UI Today! (yes, yes, again!)
All the awesomeness coming you way:
Ignite UI: What’s New in 13.1 HTML5, jQuery & ASP.NET MVC Controls
As always Free Trial is available and it will soon be serving up 13.1 code for you to try!

Just in case you are joining us tomorrow for a day filled with JavaScript related talks at JS Saturday and the topic of Responsive Web Design and Fluid design interest you – make sure to visit the session by our very own Konstantin Dinev!

I’d love to hear some thoughts, so leave a comment down below or @DamyanPetev.

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

Ignite UI jQuery Grid Column Moving

dpetev — Fri, 22 Feb 2013 16:47:00 GMT

The Grid is one of Ignite UI’s bread and butter controls and its feature set just.. keeps growing! I guess that fact that Infragistics has done quite a few grid controls over the years helps. Ome of the latest additions is the The Column Moving feature – it is still in a CTP stage for the current release (not for long I should add, 13.1 is coming our way!). It’s a really simple feature at first glance as with other ‘simple’ Grid features they turn out to be not that simple. In all seriousness, there’s barely such a thing as ‘simple’ grid feature because of the way event the smallest change can have impact on multiple other modules. And while there might be some odd end to polish, you can start using the feature now or at the very least get to know it a little.

The Column Moving allows the users to change the order of columns. From a user standpoint things are pretty well rounded – they can simple pick column headers and drag them to the desired position or open up a menu with convenient shortcuts as seen on the shot to the side here. Finally, an additional dialog with columns listed in order to be tweaked (interestingly enough inside is an Ignite UI Tree with drag and drop enabled nodes from the columns).

Getting started

As a developer you’d be pretty happy to find things are kept as easy as can be – enabling such a feature is straightforward – when referencing recourses make sure to include the column moving widget and the add the feature:

 $.ig.loader("igGrid.ColumnMoving", function () {
    $("#grid").igGrid({
        autoGenerateColumns: true,
        dataSource: "@Url.Action("People","Home")",
        features: [
            {
                name: "ColumnMoving",
                mode: "deferred",
                type: "render"
            }
        ]
    });
});
 

And when using the ASP.NET MVC helper you don’t need to define recourses yourself:

 @(Html.Infragistics().Grid(Model).ID("Grid1").AutoGenerateColumns(true)
.Features(feature =>
    {
        feature.ColumnMoving().Mode(MovingMode.Immediate).MoveType(MovingType.Dom);
    })
.DataBind()
.Render()
)
 

Perhaps you’ve notice the subtle differences between the two in term of settings – the Column Moving has two modes and two more modes we call types . The DOM move type will instruct the feature to move only the affected table cells (<td> nodes) in the DOM tree. The other type will move the columns in the data source and then renders the grid again. More on that later on.

The immediate vs. deferred only affects the drag and drop interaction when moving and as you can imagine immediate just moves the column constantly as you drag it around. The deferred only moves on release and in the mean time it provides only an indicator where you’d be dropping that column:

Pretty simple, no? I find the immediate drag & drop reaction more immersive, don’t know just feels like that for me – but it comes at a price of doing a lot of extra movement in between, that can be otherwise omitted. The thing to note here is that the immediate mode (as duly noted in its jQuery API) doesn’t really mix well with the ‘render’ type – imagine dragging around the column header and have the grid underneath re-rendering constantly. It’s just too much of a hassle to attempt to compensate for that, so when mode is immediate, the type will only be ‘dom’ (even if you choose ‘render’).

Control

Out of the twofold nature of the interaction with the feature come two additional settings – you can turn on and off the the additional move menu globally, or both with the drag & drop capabilities on per column basis. The menu is integrated with the Feature Chooser, which is to say that if there are other features using it (such as Column Hiding), disabling the move menu will only remove the relevant parts to that feature. This is done globally though the ‘addMovingDropdown’ setting:

     //....
    features: [
        {
            name: "ColumnMoving",
            addMovingDropdown: false
        }
    ]
    //.....
 

The per-column settings also let you can disallow the drag and drop functionality for the column (since it’s based on jQuery UI Draggable it means that the widget will not be initialized for the column) in addition to the menu:

         //....
        features: [
            {
                name: "ColumnMoving",
                columnSettings: [
                    {
                        columnKey: "Demographics",
                        allowMoving: false
                    }
                ]
            }
        ]
        //....
 

Note this doesn’t really fix the column in it’s place – as I explained it merely doesn’t create the draggable widget and Feature chooser menu for that column. However, since other columns can move, they can and probably will push that column out of it’s place. Also the API method can move that column regardless.

Notes, tips and tricks

The feature offers a single method, but a ton of settings and events you can make use of in creating amazing grid experiences. There are some options that probably didn’t make it to the jQuery API page(happens, being CTP and all):

The hidden settings

The column header users drag can be made transparent though the ‘dragHelperOpacity’ as it is exactly that the helper for the jQuery UI Draggable and this directly corresponds to the opacity property.

There are two tolerance settings for this feature and they are both only regarding the Drag&Drop interaction side of Column Moving – besides letting you dragging the header around the feature is also kind enough to scroll the grid for you when you go near the edge. The edge is actually a distance threshold defined by the ‘movingScrollTolerance’ property (length (in pixels) below which horizontal scrolling occurs) and supported by ‘scrollDelta’ that dictated how much should be scrolled each time.

Then you also have the ‘movingAcceptanceTolerance’ which is how the feature checks if you are close to a possible column drop point and the column/indicator should be moved there. I think a visual explanation will be great for this. The default accept tolerance is 20px which means that if the edge of the helper moves closer that that to some edge, that edge will be accepted as target position for column moving, see what I mean:

There’s a very important note for the tolerance settings – use wisely and with caution – imagine what will happen if you crank up the tolerance too much, like wider than your columns? The feature will totally go crazy and drag column moving will produce highly unpredictable results! I’d say those 20px as pretty confortable, but hey with great settings power comes great… you get the point!

The ‘hideHeaderContentsDuringDrag’ which is why the actual column header above is empty when dragging.

Multi-Column headers and hierarchy

The Column Moving acts really well with this (also new) feature and also plays nice with the Hierarchical version of the grid. The drag helper/header is restricted within the confines of it’s respective grid (which prevents child-parent moves in the Hierarchical Grid) and won’t be accepted outside it’s column group, so the Multi header settings are respected. There are some gotcha-s here – the API move method will believe you more that the user and attempt to move whatever you tell it to wherever – yes you can move entire header by identifier, but careful with indexes – they include the group and vary inside it as well. I might do a whole blog on that later on, but for now just thoroughly test if you combine those features.

Performance

So, back to those move types. As you might've guessed there’s a reason why the move type is exposed to the developer – it has performance implications because of the ways the actual moving is performed. Remember how data is laid in the HTML table – by columns? Of course not – it’s by rows. That means finding the right cell, detaching it and re-attaching it before/after a different target cell. That’s not that bad, but consider it is done for every row each time you move a column! It can get pretty intensive.

The re-render, on the other hand, destroys most of the grid layout and based on the already updated data source renders the data table again. So how’s that for intensive? Well, it depends kind of… Our developers noted this and I did some very quick tests to confirm this:

As a general rule of thumb, DOM Column Moving is faster for most browsers, but (surprise, surprise!) the ‘render ‘ is actually faster for IE. And, yes, I’ve tested IE10 thinking there’s probably some sort of an error, but even with small sample numbers the difference was so huge that there’s no way it’s wrong. No idea why – is it the querying of a whole bunch of elements or the DOM manipulation that’s the bottleneck, but it turns out re-rendering is faster for IE.

But, hey, that’s just interesting info – there’s no reason for you to worry or even consider this an issue – there’s an easy solution – please, please use Paging! With reasonable page size the time it takes to move a column of 2000 rows takes a plunge down to a snappy, pretty much instant, 50ms range. Trust me when I say it makes all the difference and it’s an absolute must if you plan on a lot of data. And if for whatever reason you need it all in a single view(page) then enable Row Virtualization! Paging kind of delivers the same functionality and the conclusion is an old one – virtualization is totally awesome with big data and a virtualized grid handles thousands of records like a boss!

Making use of events to enhance functionality

Personally there’s something that bugs me about the immediate mode of the feature.. When dragging columns around in a very demo grid, with all healthy mix of easily distinguishable text/numbers mix in the columns, it’s all good and merry. But when you hit a grid with like all numbers – like it’s very likely to happen in some scenarios – I find it really hard to track my column around. There’s no indicator with immediate, the only notice really is the empty header if hasn’t been disabled or the same text following you around. Good thing the Column Moving Events are many and give you precious information needed to control and/or enhance functionality.

Well I figured I can show you how to events and enrich the experience at the same time. I’ve decided to cheat a bit and steal the Sorting feature indication by highlighting the column currently moving with the following class:

 <style>
    .ui-iggrid td.ui-state-moving {
        background: 0;
        background-color: #c2e8f8;
        color: #333;
        font-weight: normal;
        text-shadow: 0 1px 0 rgba(255,255,255,0.8);
        border-color: #b3e2f6;
        border-width:  1px;
    }
</style>
 

Two things to note here – this is almost identical to the highlight Sorting uses, just renamed so it won’t mess with the feature’s CSS, but if you absolutely know you won’t be using Sorting or it’s highlight, it’s safe to just apply ‘ui-state-highlight’. And secondly, if you are using it with sorting CSS you might want to consider some different colors. Having said that, applying the class is extremely easy:

         features: [
            {
                name: "ColumnMoving",
                mode: "immediate",
                columnDragStart: function (event, ui) {
                    ui.owner.element.find('tr td:nth-child(' + (ui.columnIndex + 1) + ')').addClass("ui-state-moving");
                    colMovingKey = ui.columnKey;
                },
                columnDragEnd: function (event, ui) {
                    var grid = $(event.target).data('igGrid');
                    var newindex = grid.options.columns.indexOf(grid.columnByKey(colMovingKey)) + 1;
                    grid.element.find('tr td:nth-child(' + newindex + ')').removeClass("ui-state-moving");
                }
            }
        ]
 

The drag start and end events correspond directly to the jQuery UI Draggable events, and they even relay most of the common arguments. The other events include a column moving and moved events to react before and after a move, and then a whole bunch of events related to the additional menu and dialog.

The above snippet is only fit for a very basic layout (the demos include a somewhat acceptable version with multi-column headers as well, so check them out). The result looks something like this – just imagine a much bigger grid and better image quality:

As I always say, it’s not as much about modifying the feature, but showing you can quickly apply enhancements and control at various points of interest. And it’s that easy!

Resources

So besides all the links sprinkled all over, here’s a quick and useful list of info and demos:

Column Moving and Column Moving API samples for you to check out. Also for the Hierarchical Grid with Column moving and Hierarchical Grid Column Moving API!
jQuery API Reference for the Column Moving feature
ASP.NET MVC Helper API Reference for the Column Moving feature
A fairly elaborate ASP.NET MVC Demo using AdventureWorks () with both MVC Helper and script definitions of basic grid setup, enhanced with the above highlight, and in combination with Multi-Column Headers and highlighting.
Multi-Column Moving Demo on JSFiddle
And finally.. Go get yours:

I’d love to hear some thoughts, so leave a comment down below or @DamyanPetev.

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

Merging Cells with the Infragistics jQuery Grids

dpetev — Thu, 03 May 2012 10:55:00 GMT

Merged Cells is a new addition to the arsenal of features in the jQuery Grids by Infragistics, even though it is introduced as CTP (Community Technology Preview) for the first release of 2012. Like with most features this one is also realized and managed by its own widget and there are several benefits to that. For starters, that said widget doesn’t need to be loaded unless you need its functionality, combined with everything built like that - it just adds up. It also means that most of those can be shared for both the flat data and the hierarchical grid. It also attaches its functionality to the grid and the actual grid is unaware such thing is active at all. It’s is not yet polished as you’d might guess, but that shouldn’t worry you, on the contrary – the whole point of these preview is us sharing what we have so far, hopefully it is something you’d like and get you excited about it, perhaps give it a try, share your thoughts, make a feature request and so on. This feature sure is exciting and it has plenty of ways to come to its own in the future, so let’s have a closer look!

Merging Cells

While I say merging cells, that might be somewhat deceiving (if you are currently imagining excel-style user operated merging of two random and unrelated cells, then yes it is deceiving, indeed). Thing is, users are not really required to do anything and this feature doesn’t allow merging of unrelated cells. What it does is combining neighbouring cells with the same values. You may ask what good would that do? Well, the whole point of this feature is to provide visual aid for the user - think of it as a visual cue that would help identifying same values by grouping or merging them in a sense. The widget will do just that – merge cells in a column that are next to each other and have identical values. Again the best usage for such a feature would be to seamlessly spot “areas” with specific repeating values, with perhaps the strongest usability and benefit being after sorting. Of course, a visual feature is not fully introduced without an image. Here’s the jQuery grid displaying the usual Northwind Customers – with Merged Cells enabled once you sort to stack identical values next to each other they will be nicely styled so the user can easily spot just where are those groups:

Now that makes it crystal clear, doesn’t it? Moving on to how to get that feature running and what it will offer.

Steps

As with other features, as mentioned, this one can and should be loaded when it’s needed. For that you have our own scripts and styles loader widget and all you have to do is state you want that feature as a resource along with an igGrid or igHierarchical grid:

$.ig.loader({
    scriptPath: '../../Scipts/js/',
    cssPath: '../../Content/css/',
    resources: 'igGrid.Paging.MergedCells.Sorting'
});

That can as always be done using our ASP.NET (MVC) helpers and naturally you can swap the ‘igGrid’ for ‘igHierarchicalGrid’ in that snippet when your case requires.

Setting up the feature is much like all others – regardless of the rest of your grid definition, added to the features and it looks like so:

$("#grid").igGrid({
    dataSource: "Home/Customers",
    //alternateRowStyles : false,
    autoGenerateColumns: false,
    columns: [
        { headerText: "ID", key: "CustomerID"},
        { headerText: "Company Name", key: "CompanyName"},
        { headerText: "Contact Name", key: "ContactName"},
        { headerText: "Country", key: "Country"},
        { headerText: "City", key: "City"}
    ],
    features: [
    {
        name: "Sorting", type: "local", mode: "multiple"
    },
    {
        name: "Paging", pageSize: 10, type: "local"
    },
    {
        name: "MergedCells", initialState: "merged"
    }]
});

So far the feature only comes with this setting – what it does is controlling when the merging effect should occur. Setting it as above to merged would cause the grid to be initialized with cells merged, meaning as soon as you load if there are neighbouring same values – they get the proper treatment and it can look like:

That’s like one country above (depends on your data after all) so not as spectacular as when you have your values sorted. And after sorting is exactly when the cell will be merged, if you leave or set that property to ‘regular’.

Further enhancements

Multiple column sorting and merging

Having the basic functionality started, notice in the grid definition above, the Sorting mode is set to multiple. That means multiple columns can be sorted. Therefore, multiple columns will have similar values next to each other and they will all have their cells merged. Here’s how that would look when you sort both countries, like above, and then cities:

Hierarchy

As mentioned this widget will happily plug to the hierarchical jQuery grid as well and there are just a few twists. Merged Cells will affect child layouts if you leave the initial state to merged. However you can provide the same treatment for them as the parent grid via feature inheritance – allow for sorting to be inherited. Also set the initial state of the Merged Cells feature to regular and allow for it to be inherited as well. Here’s a snippet of hot the features would look for the hierarchical grid definition:

features: [
    {
        name: "Sorting", type: "local", mode: "multiple", inherit: true
    },
    {
        name: "MergedCells", initialState: "regular", inherit: true
    }]

And that would result in the visual separation of the values in the sorted columns for both parent and child layouts:

Events

As expected the feature will fire events to allow you to gather information about the process and have control over it. Two events are fired one as the merging is in progress (the ‘-ing’ which is almost always cancellable so you can prevent the operation based on some criteria) and one after a merging has occurred (‘-ed’). Naturally you can use the event arguments to gain access to the grid when the feature was activated or to the widget itself or the staring row. There are also some feature-specific things that are provided for you, like the repeated value that caused cells to be grouped and how many of them were included. Here’s a sample binding to the ‘-ed’ event:

$(document).delegate("#grid", "iggridmergedcellscellsmerged", function (evt, ui) {
    console.log("Merged cells with the value: " + ui.value);
    console.log("Merged group starts from row: " + ui.rowIndex + " and includes " + ui.count + " cells.");
});

Wrapping Up

The Merged Cells in an excellent feature to visually aid in distinguishing groups of same values in sorted columns. It makes those columns seem less cluttered, more organized by visually reducing the amount of text in them (as the greyed cells just don’t stand out as much). It all results in a more intelligible layout after sorting and actually functional and pleasing visual effect to enhance the experience for the user.

12.1 is incredibly near! Keep an eye on the blogs, follow us on Twitter @Infragistics and Facebook. Speaking of which - we’ve been showing you how to do some pretty awesome stuff using our controls and perhaps it’s time for you to show us your best? Follow the link above to our Facebook page for more info and enter the competition for building the best app and a chance to win an iPad3!

UPDATE: Demo Project available for download! Both flat and hierarchical grid implementatons using only client-side scripts as well as the MVC helper. Keep in mind you will need at least a Trial version of our jQuery controls (it's free!) to build and run the views using the helper.

MVVM Support with KnockoutJS in NetAdvantage for jQuery 2012 Vol.1

mmateev — Tue, 24 Apr 2012 17:58:00 GMT

Probably many developers who have experience with XAML applications are familiar with Model View ViewModel (MVVM) design pattern. Specialists who work on WEB projects now have the opportunity to implement this pattern in the client portion of the applications using KnockoutJS.

Knockout is a JavaScript library that helps you to create rich, responsive display and editor user interfaces with a clean underlying data model. Any time you have sections of UI that update dynamically (e.g., changing depending on the user’s actions or when an external data source changes), KO can help you implement it more simply and maintainable.

This article is about how to integrate KnockoutJS with the Infragistics jQuery Grids in 12.1 release. Now with NetAdvantage for jQuery 12.1 it is possible to take advantage of the MVVM pattern within your web applications and full two-way data binding support , both for cell/row updates, as well as add row/delete row. This post also could help XAML programmers to transit to HTML + JavaScript world, while carrying best practices such as MVVM pattern over to the new world.

With Knockout you will have:

Elegant dependency tracking - automatically updates the right parts of your UI whenever your data model changes.
Declarative bindings - a simple and obvious way to connect parts of your UI to your data model. You can construct a complex dynamic UIs easily using arbitrarily nested binding contexts.

Knockout is a pure JavaScript library - works with any server or client-side technology. It can be added on top of your existing web application without requiring major architectural changes. KO is a compact - around 13kb after gzipping and works on any mainstream browser (IE 6+, Firefox 2+, Chrome, Safari, others).

It is a challenge for each company, that has jQuery components to put together jQuery and Knockout and offer a real MVVM support for WEB components. To be possible to support notifications when the data in ViewModel is changed, components have Knockout extensions. In NetAdvantage for jQuery 2012 Vol.1 you could find KO extensions from Infragistics jQuery Grid, Hierarchical Grid and Data Source.

You will learn how to use KnockoutJS bindings with the igGrid widget via simple ASP.Net MVC3 application. This application that provides information about the Customers from Northwind sample database. Data is stored in Microsoft SQL Server. Business objects are created via Entity Framework

Prerequisites

You need to add in the project:

Infragistics 12.1 release scripts(under Scripts folder) and styles (under Content folder):

It is important to not to forget Infragistics knockout extensions:

infragistics.datasource.knockoutjs.js
infragistics.ui.grid.knockout-extensions.js

Knockout library: knockout.js (current sample uses version 2.0.0)
Knockout mapping: knockout.mapping-latest.js (current sample uses version 2.0) : this file is used from Infragistics knockout extensions.
Northwind sample data base

How to start:

You need to have data: in this sample is used Entity Framework to create business objects from Northwind database

Knockout Extensions

Knockout extensions should be loaded as resources in your page.

<script type="text/javascript">

    $.ig.loader({

        scriptPath: "../../Scripts/Infragistics/js/", 

        cssPath: "../../Content/Infragistics/css/",

        resources: "igGrid.*,extensions/infragistics.datasource.knockoutjs.js,extensions/infragistics.ui.grid.knockout-extensions.js",

        theme: "metro"

    });

  

</script>

MVC Controller:

When you want to use Infragistics jQuery components and Knockout you have no need to use ASP.Net MVC, but MVC framework helps developers to create quickly line of business applications. It also helps Windows developers to create easily WEB applications.

In this sample MVC controller is used to maintain data.

The method “Customers” is used to serialize data in JSON

#region Customers

 public JsonResult Customers()

 {

     return Json(nw.Customers, JsonRequestBehavior.AllowGet);

 }

 #endregion //Customers

Northwind data is a helper class used to deserialize JSON where data is a response data key

public class NorthwindData

{

    public IEnumerable<Customer> data { get; set; }

}

UpdateCustomers action is used to update Northwind database. View can use use this method to pass updated data from views to the controller.

#region UpdateCustomers

[HttpPost]

public ActionResult UpdateCustomers(NorthwindData customers)

{

    var x = customers.data;

  

    foreach (Customer cust in x)

    {

        Customer oldCust = nw.Customers.Where(y => y.CustomerID.Equals(cust.CustomerID)).FirstOrDefault();

        if (oldCust == null)

        {

            nw.Customers.AddObject(cust);

        }

        else

        {

            oldCust.Country = cust.Country;

            oldCust.City = cust.City;

            oldCust.ContactName = cust.ContactName;

            oldCust.Address = cust.Address;

            oldCust.Phone = cust.Phone;

        }

    }

  

    nw.SaveChanges();

    return null;

}

#endregion //UpdateCustomers

Item is a class, used to represent customer in the ViewModel.

function Item(CustomerID, Country, ContactName, CompanyName, City, Address, Phone) {

        return {

            CustomerID: ko.observable(CustomerID),

            Country: ko.observable(Country),

            ContactName: ko.observable(ContactName),

            CompanyName: ko.observable(CompanyName),

            City: ko.observable(City),                

            Address: ko.observable(Address),

            Phone: ko.observable(Phone)

        };

    };

ViewModel

The ViewModel contains observableArray to present a list with customers. It also has a computed field, named recordsCount, used to display the total number of customers.

function ItemsViewModel() {

    var self = this;

  

    self.data = ko.observableArray([]);

  

    self.recordsCount = ko.computed(function () {

        var count = 0;

        count = self.data().length;

        return count;

    });

  

    for (var i = 0; i < db.length; i++) {

        self.data.push(new Item(db[i].CustomerID, db[i].Country, db[i].ContactName, db[i].CompanyName, db[i].City, db[i].Address, db[i].Phone));

    }

};

Data Maintenance:

Load data using the MVC Controller:

You could use jQuery.ajax() to get data as JSON from the Controller. In the sample this approach is used to load data about the customers.

$.ajax({ url: url, success: function (data) {

               db = data;

               itemsModel = new ItemsViewModel();

               ko.applyBindings(itemsModel);

           },

               type: 'POST', dataType: 'json'

           });

Update the data source:

The same approach with jQuery.ajax() is used to update the Northwind database. In this case is used action “UpdateCustomers” in the our MVC controller.

function UpdateCustomers() {

    $("#grid").igGrid("commit");  

   var updatedData = ko.toJSON(itemsModel);

   $.ajax({

       url: updateUrl,

       type: "POST",

       data: updatedData,

       dataType: "json",

       contentType: "application/json; charset=utf-8",

       success: function () {

           console.log('Update succeeded!');

       },

       error: function () {

           console.log('Update failed!');

       }

   });

};

JavaScript method “UpdateCustomers” is called when an update button is clicked.

<div style="position: relative; width: 180px; height: 30px; top: 80px; left: 20px">

    <button id="updateBtn" style="height: 30px; width: 180px;"  onclick="UpdateCustomers()">Update Customers</button>

</div>

Data Binding and Infragistics jQuery Grid

You need “data-bind” clause to create igGrid and bind it to the data source. In this case data source is the option “data” from our ViewModel.

<table id="grid" data-bind="igGrid: {dataSource: data, width: 1100, height: 500, primaryKey: 'CustomerID', autoCommit: false, >

                            features: [ {

                                name: 'Updating', editMode: 'row',

                                }

                            ],

                            autoGenerateColumns: false, 

                            columns: [

                                {key: 'CustomerID', headerText: 'Customer ID', width: 80, dataType: 'string'},

                                {key: 'Country', headerText: 'Country', width: 150, dataType: 'string'},

                                {key: 'City', headerText: 'City', width: 100, dataType: 'string'},

                                {key: 'ContactName', headerText: 'Contact Name', width: 270, dataType: 'string'},

                                {key: 'CompanyName', headerText: 'Company Name', width: 200, dataType: 'string'},

                                {key: 'Address', headerText: 'Address', width: 200, dataType: 'string'},

                                {key: 'Phone', headerText: 'Phone', width: 100, dataType: 'string'}

                            ]

  

                         }"

        </table>

Calculated properties:

Calculated property (option) recordsCount is used to represent the total number of customers.

self.recordsCount = ko.computed(function () {

                    var count = 0;

                    count = self.data().length;

                    return count;

                });

You could bind this property to some HTML element (span in this case).

<div style="position: relative; width: 180px; height: 30px; top: 20px; left: 20px">

     <label><b>Customers count:</b> </label><span  data-bind="text: recordsCount" ></span>

 </div>

To gather all in one

Here is the whole page with igGird, Knockout and MVVM implementation.

@{

    ViewBag.Title = "CustomersNorthwind";

}

<script type="text/javascript">   1:  

    $.ig.loader({

        scriptPath: "../../Scripts/Infragistics/js/", 

        cssPath: "../../Content/Infragistics/css/",

        resources: "igGrid.*,extensions/infragistics.datasource.knockoutjs.js,extensions/infragistics.ui.grid.knockout-extensions.js",

        theme: "metro"

    });

  
</script>
  

<script type="text/javascript">

    var url = "Home/Customers/";

    var updateUrl = "Home/UpdateCustomers/"

    var db, itemsModel;

  

  

    function Item(CustomerID, Country, ContactName, CompanyName, City, Address, Phone) {

            return {

                CustomerID: ko.observable(CustomerID),

                Country: ko.observable(Country),

                ContactName: ko.observable(ContactName),

                CompanyName: ko.observable(CompanyName),

                City: ko.observable(City),                

                Address: ko.observable(Address),

                Phone: ko.observable(Phone)

            };

        };

  

         function UpdateCustomers() {

             $("#grid").igGrid("commit");  

            var updatedData = ko.toJSON(itemsModel);

            $.ajax({

                url: updateUrl,

                type: "POST",

                data: updatedData,

                dataType: "json",

                contentType: "application/json; charset=utf-8",

                success: function () {

                    console.log('Update succeeded!');

                },

                error: function () {

                    console.log('Update failed!');

                }

            });

        };

  

        $.ig.loader(function () {

  

            $.ajax({ url: url, success: function (data) {

                db = data;

                itemsModel = new ItemsViewModel();

                ko.applyBindings(itemsModel);

            },

                type: 'POST', dataType: 'json'

            });

            function ItemsViewModel() {

                var self = this;

  

                self.data = ko.observableArray([]);

  

                self.recordsCount = ko.computed(function () {

                    var count = 0;

                    count = self.data().length;

                    return count;

                });

  

                for (var i = 0; i < db.length; i++) {

                    self.data.push(new Item(db[i].CustomerID, db[i].Country, db[i].ContactName, db[i].CompanyName, db[i].City, db[i].Address, db[i].Phone));

                }

            };

  

  

        });
</script>

<h2>Customers Northwind</h2>

  

<br />

<div style="display: block; height: 600px; width: 1180px;">

    <div style="float: left; width: 1150px; height: 500px; margin-right: 5px;">

        <table id="grid" data-bind="igGrid: {dataSource: data, width: 1100, height: 500, primaryKey: 'CustomerID', autoCommit: false, >

                            features: [ {

                                name: 'Updating', editMode: 'row',

                                }

                            ],

                            autoGenerateColumns: false, 

                            columns: [

                                {key: 'CustomerID', headerText: 'Customer ID', width: 80, dataType: 'string'},

                                {key: 'Country', headerText: 'Country', width: 150, dataType: 'string'},

                                {key: 'City', headerText: 'City', width: 100, dataType: 'string'},

                                {key: 'ContactName', headerText: 'Contact Name', width: 270, dataType: 'string'},

                                {key: 'CompanyName', headerText: 'Company Name', width: 200, dataType: 'string'},

                                {key: 'Address', headerText: 'Address', width: 200, dataType: 'string'},

                                {key: 'Phone', headerText: 'Phone', width: 100, dataType: 'string'}

                            ]

  

                         }"

        </table>

    </div>

    <br />

    <div style="position: relative; width: 180px; height: 30px; top: 20px; left: 20px">

        <label><b>Customers count:</b> </label><span  data-bind="text: recordsCount" ></span>

    </div>

    <div style="position: relative; width: 180px; height: 30px; top: 80px; left: 20px">

        <button id="updateBtn" style="height: 30px; width: 180px;"  onclick="UpdateCustomers()">Update Customers</button>

    </div>

    

</div>

How it works

Here is the default data in the Customers table.

Start the application:

Update records:

Change the address in the first row.

Updated filed is still not committed.

When you click “Update Customers” button data is committed our ViewModel (ItemsViewModel class instance) is updated and data is send as JSON to the Controller using jQuery.ajax()

Insert records

You could use the standard “Insert row” functionality of the igGrid.

Data in the jQuery Grid is updated and you could use the same approach like in update records: commit data and send it to the controller to be possible to save changes in SQL Server.

Delete records

Delete records works in the same way like update and insert.

MVVM implementation with Knockout and igGrid is a pretty easy. You could use Infragistics Hierarchical Grid in similar scenarios when you have hierarchical data. Knockout support in NetAdvantage for jQuery is CTP. Expect in the next releases (after 12.1) more new features for MVVM support.

Demo application will be available for download after NetAdvantage 2012 Vol.1 RTM release date.

You can try this product very soon. Follow news from Infragistics in http://infragistics.com/ and twitter: @infragistics for more information about new Infragistics products.

Column Templates for the jQuery Grids

dpetev — Tue, 17 Apr 2012 15:45:00 GMT

In my last blog I mentioned that our jQuery Grids are getting a new column template option that would also be using our new high performance Templating engine and in this blog will try to expand on both templating and what can you do with it in the grids. And, yes, I keep mentioning grids because this will seamlessly work with both the flat data Grid and the Hierarchical Grid(as it would create instances of the flat grid to build its nested layouts) - you will soon be able to apply templates on every column.

Now as mentioned before, the Templating Engine functionality is integrated with multiple controls,among which are the grids. That translates in a few benefits – you get igTemplating scripts the moment you load the grid and the grid internally will call the templating function and provide data and so on. All you have to worry about is providing the template string. So the way templates work with the controls remains pretty much the same and you might not feel the change at all. When you do, though, you can start use the new column template functionality – similar to the existing row template, but rather than making a template for all the columns in the row, you can now create a template for just that one column you are interested in! That should be a step forward in terms of flexibility and getting what you need done fast.

Just a few steps

Adding in scripts

Now that is yet another subject we’ve been sharing bits here and there – for 12.1 we have a loader control that is there to handle scripts and styles for you (you can check out this blog post on using the jQuery Loader to manage resources). The best part is that it follows the dependencies of the control you need and loads them too. That should explain why this:

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

would result in loading those files:

Notice the templating in there? Of course the same result would be observed if you use Hierarchical Grid instead or the ASP.NET MVC wrapper:

@( Html.Infragistics().Loader()
      .CssPath("../../Content/css/")
      .ScriptPath("../../Scripts/js/")
      .Render())
@( Html.Infragistics()
    .Grid(Model) //continues...

Template strings

As mentioned above, functionality remains the same – the grid will handle templating internally and you provide the sting only. For this example let’s assume you are to display Customers (and optionally Orders) from the Northwind database and you already have a controller action exposing it. That means that in your templates you can use the data fields by name (just keep in mind it is case sensitive). Templates can be provided within or separately from the grid definition if you want to keep it neat. Let’s turn the ‘Country’ field into a flag rather than simple text:

var CountryTemplate = "<img alt=\"${Country}\" src=\"http://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/Flag_of_${Country}.svg/167px-Flag_of_${Country}.svg.png\" ></img>";

A simple <img> tag would do the trick and the source images are actually the thumbnails from Wikimedia’s Sovereign-state flags page. While this would work for most, there are some exceptions (like UK and USA as seen in Northwind, rather than the full name used for the images) and the results are not quite there yet:

To improve on that we would use some conditional blocks to make our template flexible. The engine provides support for logic like the following:

{{if <condition1>}} <template1> {{elseif <condition2>}} <template2> {{else}} <default template> {{/if}}

And here’s the full template once we apply that:

var CountryTemplate = "{{if ${Country} == \'UK\'}} <img alt=\"${Country}\" src=\"http://upload.wikimedia.org/wikipedia/commons/thumb/a/ae/Flag_of_the_United_Kingdom.svg/200px-Flag_of_the_United_Kingdom.svg.png\""
 + "{{elseif ${Country} == \'USA\'}} <img alt=\"${Country}\" src=\"http://upload.wikimedia.org/wikipedia/commons/thumb/a/a4/Flag_of_the_United_States.svg/190px-Flag_of_the_United_States.svg.png\" ></img>"
 + "{{else}} <img alt=\"${Country}\" src=\"http://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/Flag_of_${Country}.svg/167px-Flag_of_${Country}.svg.png\" ></img> {{/if}}";

And while still on the subject of conditional templates let’s do little trick for the column showing the customer ID. For the sake of the example lets have a special treatment for countries begging with ‘U’. How would we do that? The trick is that when you use conditional blocks, what is inside that block will be compiled as JavaScript code, unlike simple substitution that will only produce a string for a performance boost. That means you can call various functions and use JavaScript logic there:

var CustomerTemplate = '# Invisible comment text # {{if ${Country}.lastIndexOf("U", 0) === 0 }}<p style=\'color:rgb(0, 175, 235);\'>Conpany: ${CompanyName} <p> {{else}}Customer ID: ${CustomerID} {{/if}}';

Note the usage of ‘lastIndexOf’ method, which would compare the index of the last discovered ‘U’ char while checking only the first position in the country and in the same way this can be a custom function to perform more complicated checks. Results from the above improvements look like so:

Note the middle row displays the company name instead the the ID and the flag is now with proper source.

Besides complicated conditional logic you can also use ‘each’ block to produce the kind of template you need. Examples for that would be creating HTML list to be transformed into a tree control or select element. In both cases the loop would be required to go through all the internal items:

var OrdersTemplate = "<select id=\"IdSelect\">{{each ${Orders} }}  <option>${Orders.OrderID}</option>  {{/each}}</select>";

The default select will contain all the OrderID-s for the current record. You can drill down the hierarchy even though some of those fields might not be included in the layout(but are in the data) and you can assign various attributes to your template markup which can then be used as targets for scripts and styles. Using that technique can provide great versatility in regards to what kind of content you have in your grid (turning numbers into ratings, taking child data to create a chart, etc. ).

Setting up the grid

What is left is to add a grid to your page (flat data or a hierarchical) and use the new ‘template’ property available for column options (of course you can apply templates to the child layouts). In the definition you will see the templates defined above assigned to columns, a template applied to the child layout inline and the dataRendered event used to transform the select elements into igCombo controls:

$("#grid").igHierarchicalGrid({
    height: "400px",
    width: "650px",
    autoGenerateColumns: false,
    autoGenerateLayouts: false,
    initialDataBindDepth: 1,
    primaryKey: "CustomerID",
    defaultChildrenDataProperty: "Orders",
    dataSource: "/Home/CustomersAndOrders",
    columns: [
                { headerText: "Customer ID", key: "CustomerID", dataType: "string"},
                { headerText: "City", key: "City", dataType: "string" },
                { headerText: "Country", key: "Country", dataType: "string", template: CountryTemplate },
                { headerText: "Orders", key: "EntityState", template: OrdersTemplate} //this column is just used to host the selects
        ],
    columnLayouts: [{
        key: "Orders",
        childrenDataProperty: "Orders",
        autoGenerateColumns: false,
        autoGenerateLayouts: false,
        primaryKey: "OrderID",
        columns: [
                { headerText: "Order ID", key: "OrderID", dataType: "number" },
                { headerText: "Freight", key: "Freight", dataType: "number", template: "Freight: <b>${Freight}</b>" },
                { headerText: "Shipped Date", key: "ShippedDate", dataType: "date" }
            ],
        features: [
                { name: "GroupBy",
                    tyoe: "local"
                }
            ]
    }],
    features: [
        { name: "Paging",
            type: "local",
            pageSize: 10,
            showPageSizeDropDown: false
        },
        { name: "Sorting",
            type: "local"
        }
        ],
        dataRendered: function (evt, ui) {
            $("select[id~=\"IdSelect\"]").igCombo({
                width: "100px",
                selectionChanged: function (evt, ui) {
                    ui.owner.element.parent().append("Selected: " + ui.items[0].text);
                   }
             });
             //clear selections
             $("select[id~=\"IdSelect\"]").igCombo("selectedIndex", -1);
    }
});

While the logic provided to handle the selection changed on the combo is rather simplistic, it is there to mark the possibility. And the resulting grid from the definition above combined with the templates looks like this:

Conclusion

The Templating Engine provides plenty of functionality and now with column templates you can apply that just where it’s needed with familiar experience. While the snippet above uses a hierarchical grid, it is just to show it is possible to template the child layouts and the flat data grid would be templated in very much the same manner. You’ve seen some ideas on how you can make use of such features, but really what you can do with that is down to your needs and creativity!

Update: Download the demo project - an ASP.NET MVC application used as base, with two views - one where the grid is defined using the helper and one with nothing but pure script. Keep in mind you will need at least a Trial version of our jQuery controls (it's free!).

What is Continuous Virtualization in the jQuery Grids?

dpetev — Wed, 04 Apr 2012 15:35:00 GMT

Get the lowdown on the virtualization that never stops, so to speak… Soon enough the countdown to 12.1 will be over and what you will find named as Continuous Virtualization is an awesome new feature. It is designed specifically for hierarchical data – therefore finds it’s place as feature for our powerful jQuery Grids, more specifically providing virtualization for hierarchical and grouped layouts. We are looking forward to share all the new goodness that is ahead and we want you to be as excited about them as we are! So, to give you a sneak peak, lets talk virtualization. Of course, you would need some basics on the virtualization process the grids offer currently.

Virtual you say?

When performance is your goal, virtualization is pretty much your best friend. It is an unique feature of the client jQuery grid and it can greatly speed up not just the initial loading but the overall processes on the client. The idea is really simple on paper, much harder to do right and most importantly highly effective – you can have a million records in the data, but there’s no point to create UI elements for them all when the UI can only show a tiny(in comparison) amount. So instead the grid will only create pre-defined number of rows and use them to display the visible data. That in essence means two simple things – the footprint of that huge data will be actually really small and it would be about the same for various sizes of records and therefore the memory required, the load on the client (CPU usage) for the UI will not only be low, but should also remain almost the same with smaller and larger sets of data.

So, you might wonder, what happens when you do want to see those rows that have not been included? Here is where the virtualization really shines – among other possible routes of implementing it, we chose to keep that pool of rows completely static. That means the grid will not just use them – it will reuse them. Which means that those actual UI elements are not going anywhere. As the user scroll down the grid will instead replace data in the rows rather than deleting them and making new ones (which once more saves time and consumption). The rows also stay static in the DOM which is yet another benefit, as moving items in the DOM is also relatively slow process.

While all this is wonderful, there are some limitations currently – this virtualization cannot work with rows that have variable height or such that are being moved or expanded. That is essence excludes the Hierarchical Grid and the layout created by the Group By feature.

Filling the gaps

The Continuous Virtualization comes to make up for the shortfalls of the otherwise brilliantly working with flat data virtualization. Again it uses a predefined number of rows and as the user scrolls it will determine if the available rows are enough to display the ones in view are react accordingly, which again ends up with significantly reduced overhead in the DOM as just a small portion of rows, compared to the data, will exist there. There’s more – to accommodate variable row heights, after a scroll takes place the grid needs to calculate which rows should be displayed and it does that by calculating an average for the height – which makes the AvgRowHeight, that is pretty much required by the fixed virtualization, a thing of the past. Calculation is based of the actual rows the grid has available (the ones that are/were visible and created) and it is logically only an approximation rather than the true average value. That can cause same issues like incorrect scroller position and to prevent that the grid is smart enough and will adjust that positing on the fly, if such event occurs. Of course, the pool of rows will serve as a buffer for options such as a row being expanded, but if the scrolling process ‘pushes’ it out, that row will be set back to it’s default.

So besides the fact that it completes the functionality of the grids, why is it continuous? The point it that it doesn’t virtualize a pre-defined on load layout, but rather dynamic layouts that don’t exist quite yet – like a child of an expanded row and expandable new parent-rows as a result of grouping. It’s a process that just keeps ticking – constantly ready to provide virtualization and constantly re-calculating row heights and adjusting the scrollbar to provide you that seamless scrolling experience with hierarchical data of impressive sizes.

Let’s jump into an actual example and grab the all-time-favourite Nothwind and lets have our Customers information from there displayed neatly on the client by our NetAdvantage for jQuery Grid and since we are at it lets enable its GroupBy feature so we can have a look at our customers from each country for example. To take benefits from the new virtualization option we need to do some settings:

-First and foremost – enable virtualization

- Set the virtualization mode to continuous

- Define width and height for the grid – This is required for virtualization.

$("#grid").igGrid({
    // required for virtualization
    height: "300px",
    width: "700px",
    // enable virtualization
    virtualization: true,
    // -- 
    //  set to continuous
    virtualizationMode: "continuous",
    // --
    autoGenerateColumns: true,
    dataSource: "/Home/Customers",
    features: [
        { name: "GroupBy" }]
});

That code essentially combined with a server-side JSON-returning action makes for an extremely fast and easy delivered app with a client grid that supports grouping and you can pretty much do this:

If you look at the generated markup you get 54 rows :

Since the Northwind customers are only 90-something number like that isn’t all that impressive and frankly you can go without virtualization as whole. Then again those rows also contain the group header rows that are not really part of the data, but rather added by the GroupBy feature and still they are visible, thus they are in the markup. Still say you have a few of them in those fifty rows in the DOM – that’s still probably over one third of the actual data in there?

BUT.. things get drastically better when you go for the big data. No matter how much - from 500 to 10000 - when you look at the markup you will see this:

Surprised? I hope not – that was the whole point of virtualizing the UI elements in the DOM! You get a constant number of generated actual rows, unaffected by the size of your data. And what happens when you scroll to the bottom of a 10 000 ‘rows’? Do all the stuff you scroll through get added to those in the DOM? Of course not! Look:

Note that while the IDs of the rows are now in the 8000 range, but if you look closely: 8541 minus 8489 is.. well what a surprise – 52(or 53 rows)! The row count stays the same as it not affected by the position or the number of rows that have been displayed already – just like it is explained – the grid will simply keep a constant pool of reusable rows and it is not based on the data, as records come and go for those rows – it is actually based on the height of the layout!

With even more hierarchy

Now when you want a hierarchical grid this new virtualization does not only allow for the expandable rows to be virtualized. It does not only allow for them to have variable height and it does not only function with Group By. Continuous virtualization can be set for child layouts. Here’s a sample grid definition, this time using both the Customers and their orders:

$("#grid").igHierarchicalGrid({
    // required for virtualization
    height: "300px",
    width: "700px",
    // enable virtualization
    virtualization: true,
    // -- 
    //  set to continuous
    virtualizationMode: "continuous",
    // --
    autoGenerateColumns: false,
    autoGenerateLayouts: false,
    initialDataBindDepth: 1,
    primaryKey: "CustomerID",
    defaultChildrenDataProperty: "Orders",
    dataSource: "/Home/CustomersAndOrders",
    columns: [
                { headerText: "Customer ID", key: "CustomerID", dataType: "string" }, 
                { headerText: "Company Name", key: "CompanyName", dataType: "string" }, 
                { headerText: "City", key: "City", dataType: "string" }, 
                { headerText: "Country", key: "Country", dataType: "string" }
        ],
    columnLayouts: [{
        key: "Orders",
        childrenDataProperty: "Orders",
        autoGenerateColumns: false,
        autoGenerateLayouts: false,
        primaryKey: "OrderID",
        // ## BEGIN
        // enable virtualization
        virtualization: true,
        // -- 
        //  set to continuous
        virtualizationMode: "continuous",
        // ## END
        width: "300px",
        height: "50px",
        columns: [
                { headerText: "Order ID", key: "OrderID", dataType: "number" },
                { headerText: "Freight", key: "Freight", dataType: "number" }
            ],
        features: [
                { name: "GroupBy",
                  tyoe: "local"
                 }
            ]
    }],
    features: [
        { name: "GroupBy",
            type: "local"
        },
        { name: "Sorting",
            type: "local"
        }
        ]
});

This allows for each grid instance to have it's own virtualization - parent, child or child that has its own hierarchy and so on.

You might notice there’s a height of 50 defined for the child layout (as with the parent, that is required for virtualization) – that is because the number of orders just isn’t enough and since the pool of rows is based on height I had to squish it a little to force the process. Than again that is just an example (expect better ones soon) and just because of that if we take the customer with ID BONAP with just 17 orders (the most a quick look managed). When you expand that row the child layout’s markup will consist of just 10 rows. If the height is about 100 the rows would be about 20 regardless if you have 100 or 1000 records in there or they have child records themselves – and that’s, simply put, overhead reduction!

The advantage you get

No matter the size, whether it’s 100 or 10 000, the DOM structure on the client side will remain stable and most importantly low. Now imagine that was not available, imagine hierarchical structure of 10 000 rows with 100 more children each… that’s 10 000 TR elements alone and then imagine the cells in them - a certain recipe for disaster! And believe me, I do mean it – a sample with generated just as much data I tried basically made attempt to crash my browsers and while they managed – the performance was unimpressive – expanding a row (additional 100 rows) and initial loading took some time. So whenever you can’t rely on loading data on demand (or that data is so much that each piece if that kind of size) you can enable the Continuous virtualization feature and enjoy instant loading and expanding and fluid interaction with huge data. This feature does not only reduce the memory load and CPU consumption, it actually makes such high numbers feasible option.

That’s no small thing to be looking for – as soon as the new release is a fact I will add a demo project to this for you to download. Last but not least, expect more great additions – so keep eye on the community site, follows @Infragistics, give a like on Facebook and we will do our best to keep you informed, prepare you for the new stuff and hopefully have you thrilled about it!

UPDATE: Demo project available for download! Including both flat data grid virtualization in combination with grouping, as well as hierarchical grid implementation.

Combining different data sources in jQuery: Fun with the Infragistics Mashup Data Source

dpetev — Thu, 08 Mar 2012 15:10:00 GMT

Reading our blogs often makes it almost guaranteed that you have seen us mention our jQuery data source here and there or even spot it in code snippets. And while it appears alongside other controls on regular basis, its presence is actually much more impactful than what you may expect from a non-visual component. It’s one of those working their magic behind the scenes type – and that’s not in odd places, but basically with every data-bound control. The igDataScource is in fact the force that feeds data to almost every control in the NetAdvantage for JQuery family. You’d wonder then why the shy-of-attention attitude then? Well, it’s simple – it’s meant to shine while being barely noticeable and saving you all the effort that accessing and transforming data from various sources can take. The component allows for multiple types of data and origin – a range of web services and local data or even when all else fails - the option to feed your data through data-returning function. You will also find quite a few classes that extend it to provide some predefined setting for greater ease of use in the most common cases. Since we put the focus on that it’s probably time to mention that with the latest release the numbers of supported scenarios by multiple implementations got bolstered a bit more, both of them really, with a CPT (Community Technology Preview) of a very interesting ‘type’ of data source – the Mashup Data Source.

Introduction

Now this would be somewhat off-topic, but the spellchecker insists this is misspelled and I tend to disagree based on this article about Mashup on Wikipedia. And to get back on topic, on that page you can read that the term Mashup can refer to a web page/application “that uses and combines data,[..]” - I am cutting this quote off here. I believe that is more than enough to give you a decent hint what would a component, that serves as middle layer between data and data-bound controls, would do if it has ‘mashup’ in its name. Pretty straightforward - the igMashupDataSource is an extension of the base igDataScource and it allows you to combine entries from different sources into one. And since I believe this fits so well I’ll also add that the goal is “to produce enriched results that were not necessarily the original reason for producing the raw source data.” - and I find that thought very pleasing and that is exactly how it should be – this component is not just useful, but also a purveyor of satisfaction and fun – thus, the title above. And this should happen fast and easy and seamless - you still get all the familiar functionality inherited from base class or can also add to already available settings in case you have a running project.

Of course there’s a very minor catch, if you can even call it that – it’s not as simple as pointing to two sources and wait for them to be combined. For that to happen you will have to provide a common key. So while not meant to be combined, still not that random data after all? Well, depends on the case and how look at it – data can be coming from sources that know nothing of each other, yet share keys or you can tweak one to fit or one or all of the sources can be your own – either way you get a single collection consumable by a single control and you get plenty of freedom – I’d put a “fun” label on that, too. Let’s say you have data that is publicly available and therefore you’d imagine it’s two things – probably read-only and while it can be rich, it might still be missing something you need and there’s nothing you can do about that. Or can you? That’s exactly it – you can combine two compatible public sources or enrich what is available with data of your own and those can be with not only different origin, but also with different type.

Note: I’d like to stress one more time this is still a CTP component and therefore it is very possible that it may not function fully and / or some things might be very different in the final version of it.

Getting started

As mentioned before the component is an extension of the base data source class and it should come as no surprise that using it feels very familiar and not that much different. The only additional things you will see is a data source property outside the inherited one and a property indicating whether records that have no data in all sources ( therefore they are partial) should be ignored. The latter is mean to let you get just the final results you want – whether it’s all of records or just a ‘section’ of only those that exist in all sources. The data source is what I’d describe as the ‘master’ one and it takes an array of data sources itself and this is where your data from different origins comes together.

Preparations

Before that there are as always some preparations – adding the required resources and some setup to use the assorted data. Starting off with some resources which this time can be as diverse as you scenario requires – since it is a non-visual component that is built as a JavaScript class it doesn’t rely on jQuery UI scripts and therefore you can only reference the default jQuery library and the ‘ig.util.js’ where the component is. And even though you can do that and use the Mashup Data Source for anything you see fit, it’s only in rare occasions when you wouldn’t want to present it nicely too. And again how to do that comes with enough freedom(including displaying it in a table using templating as seen in our NetAdvantage for jQuery online samples ), so for this example I will use our jQuery Hierarchical grid. For that reason below in snippets and in the demo project you will see both jQuery and jQuery UI libraries, along with the full Infragistics UI scripts file.

Let’s define two sources for our main data layout – one being a small sample from the Netflix OData catalog and the other one being our very own xml file – the basic idea behind this is to take such online data and add your personal notes to it. We would need to define origin and schema to apply on those:

<!--CSS -->
<link href="../../Content/themes/min/ig/jquery.ui.custom.min.css" rel="stylesheet"
    type="text/css" />
<link href="../../Content/themes/base/ig.ui.min.css" rel="stylesheet" type="text/css" />
<!-- Scripts -->
<script src="../../Scripts/jquery-1.5.1.min.js" type="text/javascript"></script>
<script src="../../Scripts/jquery-ui-1.8.11.min.js" type="text/javascript"></script>
<script src="../../Scripts/ig.ui.min.js" type="text/javascript"></script>
<script type="text/javascript">
    var url, oDataSchema, xmlDoc, xmlSchema,
         mashupSources, dsMashup;
 
    url = "http://odata.netflix.com/Catalog/Titles?$format=json&$callback=?&$top=10";
    oDataSchema = new $.ig.DataSchema("json", { fields: [
            { name: "Id" },
            { name: "Name" },
            { name: "BoxArt" },
            { name: "AverageRating"}],
        searchField: "d"
    });
    xmlDoc = loadXMLDoc("/Content/MovieNotes.xml");
    xmlSchema = new $.ig.DataSchema("xml", {
        fields: [
                    { name: "Id", xpath: "Id" },
                    { name: "Notes", xpath: "Notes" }
                ],
        searchField: "//Movie"
    });
 
    function loadXMLDoc(dname) {
        if (window.XMLHttpRequest) {
            xhttp = new XMLHttpRequest();
        }
        else {
            xhttp = new ActiveXObject("Microsoft.XMLHTTP");
        }
        xhttp.open("GET", dname, false);
        xhttp.send();
        return xhttp.responseText;
    }
    //continues...

Of course for the XML file you can use jQuery’s get() (short for $.ajax) to perform the HTTP GET request, too. Or that xml can come from just about anywhere as long as it is presented in a form the igDataSource accepts. Defining the schemas provides the way to navigate the responses’ structure and which fields to be taken. As for the contents of the xml file it’s basically movies with ID and Notes nodes and you will find it in the demo project.

Then for a good measure I have an ASP.NET MVC action that returns JSON from a randomly generated values (again IDs and each having a collection of generated Fans with random initial and rating). The idea is that we would not only add a third source, but also it will be the sole provider for data of the child layouts in the hierarchical grid:

[ActionName("getData")]
public JsonResult JsonSource()
{ 
   var mmData = MoreMovieData.Generate();
   return Json(mmData, JsonRequestBehavior.AllowGet);
}

Note: If you do decide to go with this make sure to check out this topic on the ASP.NET forums for why we have JsonRequestBehavior.AllowGet in there and this blog by Phil Haack on the subject.

All for one

Now that we have three sources ready it is time to create our Mashup Data Source. As said before one of the things it provides is the ‘master’ dataSource which takes an array of igDataSource instances to be combined:

//--- Defining the Mashup Data Source
mashupSources = [
        { type: "remoteUrl", dataSource: url, schema: oDataSchema, responseDataType: "jsonp", primaryKey: "Id" },
        { dataSource: xmlDoc, type: "xml", primaryKey: "Id", schema: xmlSchema },
        { type: "remoteUrl", dataSource: '/Home/getData', primaryKey: "Id" }
    ];
dsMashup = new $.ig.MashupDataSource({ dataSource: mashupSources });
//--- Definition Ends
//continues...

The data source (any of them) assumes that if given a string to that identically named property instead an IQueryable or an array, then that would be an URL that points to the data. So you can safely skip the defining of type being ‘remoteUrl’ for both above. The first one is the Netflix OData as described above with URL and schema, the second is fairly obvious the xml file and the third is the JSON returning action in my Home controller.

That’s it! Now you are free to do with the data what you see fit – call its dataBind() method that does all sorts of stuff for you ( fire bind related events, analiza data, perform requests, transform data and so on) and you can use the callback function to display the data once it’s ready like in the sample linked above OR you can provide it to an UI control to display as we will now do with the igHIerarchicalGrid.

Presenting your data

It’s almost as easy as it gets – you setup the jQuery Hierarchical grid widget like you normally would and use the keys from any source freely, just like that:

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

    $("#grid").igHierarchicalGrid({
        autoGenerateColumns: false,
        autoGenerateLayouts: false,
        primaryKey: "Id",
        defaultChildrenDataProperty: "Fans",
        childrenDataProperty: "Fans",
        columns: [
            //{ headerText: "ID", key: "Id" }, /* optional row if you want to see the ID */
            {headerText: "Movie Name", key: "Name" },
            { headerText: "Image", key: "BoxArt", format: "<img src=\"{0}\" class='tooltip-grid-image'></img>" },
            { headerText: "Average Rating", key: "AverageRating" },
            { headerText: "Notes from XML", key: "Notes" }
        ],
        columnLayouts: [
            {
                autoGenerateColumns: true,
                primaryKey: "Id"
            }
        ],
        dataSource: dsMashup,
        width: "100%",
        height: "500px"
    });
});
</script>

As seen in column definitions you shouldn’t feel the difference from using a single source – and that’s the whole point! And just like that set the dataSource of the grid to our Mashup (line 20) and you are done.

Results

And just like that you have a hierarchical grid, data gathered from three different origins – all done fast and easy, keeping to familiar API and methods with a result that is not only very functional and neat but also looking quite well :

Again the first 3 columns come directly from the Netflix catalogue, the Notes next to them come from an xml file. The child layouts in this structure come from randomly generated collection on the server-side just for the sake of the example and .. for the fun, really.

Conclusion

From this blog you’ve hopefully learned a bit more about the ever so important jQuery Data Source component that is there for every data-bound control to ease your work so much. You’ve also seen what the Mashup version of it can do, how you can combine data sources into a single collection and how you can display them with style and maintain familiar feeling and existing functionality with little to no hassle. The again what you would do with it is really up to your needs and for almost any scenario this component is equipped to handle.

Some useful links: Our Online Documentation, the API references in there and the Online samples and as always you can download the demo project (ASP.NET MVC).

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.