Search results matching tag 'OData'

Tips on Drag & Drop with the Ignite UI Tree

dpetev — Wed, 19 Dec 2012 17:23:00 GMT

As promised in the previous blog on Drag & Drop with the Ignite UI Tree – some tips and tricks coming right up. If you haven’t already looked into the control’s features, now’s your chance – overview with main ones listed in the Documentation and live in the Samples. Looking at those, while each of them is rather nice, how do you think some of them would work alongside each other…and is something missing? The first one is always a potential trouble maker and the latter.. well extending functionality is fun, but as you know there are always new stuff coming with each release – might be just the thing you are missing. We do take feedback on everything through socials (links always below), there’s an active community at the Forums and you can always submit a feature request( must be logged in). Enough with the shameless plugs, on to the discussion!

Play nice?

As you’ve already seen in my previous post there are some quirks for example when you have nodes moving around with Drag and Drop and checkboxes at the same time you will loose the checkbox state and when a tri-state parent is fully checked a dropped node will respect the valid-for-all rule.

It’s merely the fact that while drag and drop is a nice interaction from a user standpoint, underneath it involves removing and adding nodes. While that is simple in itself, it does present a number of situations where it can be really tricky to preserve whatever state the node may have applied by multiple other features. There’s a similar scenario with selection when you move the selected node around – you still keep the selection data, but the visual is gone as the node is re-created.

Then you have another major feature of the Ignite UI Tree – the Load On Demand. This is an extra tricky one actually. While the moving of nodes happens entirely on the client and there’s little that can come in it’s way.. it’s really hard to add a node to a parent one that hasn’t yet populated its children. Yes, you can easily supply the UI, but the underlying data source would still contain no array of child items for you to add to. Of course, one the node populates it’s all good and cool, but as you get told everywhere users are notoriously impatient and in case they do not wait for the node to load it can get quite messy.

Do keep in mind thought, the Ignite UI toolset keeps evolving with not only new features, but general improvements as well and it’s certain Drag&Drop will become more in tune with the rest. For that reason, what I do provide for now would possible become obsolete, but it’s more of a testimony to the fact that you can enhance and extend Ignite UI controls with very little effort!

Play nice.. or I’ll make you!

So let’s get on with the modifications. The Tree’s events will be our heroes of the day as many if not all major changes are represented with them. I have one very easy fix for maintaining proper selection UI with truly minor effort – as I said it’s all really a matter of picking the right time to hook your code. I figured it’s mildly pointless to update a second selection variable on each change, so instead I will check when a drag is starting if the node in question is selected. Then when the said node is dropped I would simply use the API method provided for selection. This will in essence go and set in the new path for the node:

var selectionDirty = false;

 $('#tree').igTree({
    dragAndDrop: true,
    dragAndDropSettings: {
        dragAndDropMode: 'default',
        dragStartDelay: 100,
        revert: true,
        //simple icon-only tooltip 
        invalidMoveToMarkup: '<div><span></span><p>&nbsp;</p></div>', 
        containment: $("#tree")
    },
    dragStart: function (evt, ui) {
        // check if element is the one selected
        selectionDirty = $('#tree').igTree('isSelected', ui.element);
    },
    nodeDropped: function(evt, ui) {
        if (selectionDirty) {
            //if it was selected, re-select when dropped in new place
            var newNode = $("#tree").igTree("nodeByPath", ui.path + '_' + ui.draggable.attr('data-path').split('_').pop());
            $('#tree').igTree('select', newNode);
        }
        selectionDirty = false;
    },
    dataSource: northwindCategories,
    bindings: {
        textKey: 'CategoryName',
        primaryKey: 'CategoryID',
        valueKey: 'CategoryID',
        childDataProperty: 'Products',
        bindings: {
            textKey: 'ProductName',
            valueKey: 'ProductID',
            primaryKey: 'ProductID'
        }
    }
});
 

The difference from what you have seen before as code for the tree are the dragStart and nodeDropped events. Because those come in line of the jQuery UI Draggable & Droppable events and they can generally handle interaction between two trees, you won’t see the familiar ‘ui.owner‘ to access the tree as it’s kind of hard to tell which tree should be an owner really :) However, since I’m adding handlers separately that’s okay – I know which tree to call. Also, the tree is helpful enough to give nodes by paths – the latter you can get by combining the event provided path (the parent one) and the ID of the dropped element. The way this handles it right now should be suitable for deeper hierarchy that two as well.

Note: Remember you have the same event arguments as in jQuery UI in addition to the Tree adding some stuff (the element for example), but in the case of the drop the element is the actual target and the draggable from the original arguments is the node being dropped. The results:

You can take a very similar approach with the checkboxes in bi-state mode Trees to complement that feature, however, the tri-state limitation I feel might be the right design (respecting the parent global state). Up to you really, the option is there.

Load on Demand

As I mentioned it’s nothing that complicated stopping this from being flawless, except the very nature of loading data on demand..it’s not there yet! And if the user doesn’t want to wait things go bad. One very simple way is to decrease the expand delay (time till nodes automatically expand when dragged over) to mere nothing. This might make it work just fine if the service you use is fast enough to get ahead of the unsuspecting user. However, go too low and you risk the user triggering a whole bunch of requests on the drag path and actually making the application slower rather than faster. The solution lies in not letting the user drop on non-populated node. However, that would mean that at some point the node would expand and drop would be possible, but the helper will still be showing invalid location. It’s not such a nice experience to make the user shake the node around to force a drag and re-evaluation of the drop target. If you want just the perfect experience, you can have it with one trick – move the mouse for the user! Yup, basically listen for when the node is populated, check if the user is on top of it, and trigger a mouse move so the validation will be re-done:

  var stateHelper = { dropTarget: null, populatingNode: null, draggedNode: null };
 

 $("#tree").igTree({
     dragAndDrop: true,
     parentNodeImageClass: "parent",
     dragAndDropSettings: {
         dragAndDropMode: "move",
         customDropValidation: function (element) {
             // Validates the drop target:
             // Nodes will properly cause targets to expand (and therefore load)
             // But we must not allow actual drop before the data is loaded 
             // because we have nothing to add this node to.
             stateHelper.dropTarget = $(this);
             stateHelper.draggedNode = $(element);
             var childNodes = stateHelper.dropTarget.closest('li[data-role=node]').children('ul');
             if (childNodes.length > 0 && JSON.parse(childNodes.attr('data-populated')) === false) {
                 return false;
             }
 
             return true;
         },
         expandDelay: 500
     },
     dragStop: function(evt, ui) {
         stateHelper.dropTarget = undefined;
     },
     nodePopulated: function(evt, ui) {
         if (stateHelper.dropTarget && $.contains(ui.element, stateHelper.dropTarget)) {
             stateHelper.populatingNode = ui.element;
         }
     },
     rendered: function(evt, ui) {
         if (stateHelper.populatingNode) {
             // forse re-handling of the drag in case the user manages to 
             // shomehow keep his mouse steady when the node expands
             // this will evaluate the target again
             stateHelper.populatingNode.children('a').trigger({
                 type: 'mousemove',
                 pageX: stateHelper.draggedNode.data('draggable').position.left,
                 pageY: stateHelper.draggedNode.data('draggable').position.top
             });
             stateHelper.populatingNode = undefined;
         }
     },
     dataSourceType: 'remoteUrl',
     dataSource: 'http://services.odata.org/OData/OData.svc/Categories?$format=json&$callback=?',
     responseDataKey: "d",
     loadOnDemand: true,
     bindings: {
         textKey: 'Name',
         valueKey: 'ID',
         primaryKey: 'ID',
         childDataProperty: 'Products',
         bindings: {
             textKey: 'Name',
             valueKey: 'ID',
             primaryKey: 'ID',
             childDataProperty: 'Supplier'
         }
     }
 });
 

As you can see the Tree is bound to the oData Northwind service making calls only when needed, we listen for populated nodes and save them in the ‘stateHelper’ to later trigger the mouse move on them when the UI has been rendered.

A word on the custom validation function

The thing about this functions is that it will be overridden by the internal tree validation, which makes it the last last chance for you as a developer to return false and prevent a node drop on that target. What this also should tell you is that the internal validation will try to validate actual Ignite UI Tree as a target, so your function is not to enable something the feature won’t allow – no call will be made to it when the target is foreign. This begs the question, can you still use other targets? Yes, the drop events still fire on the drop targets! Take the Simple File Manager as an example – the trick is in the usage of the droppable events instead!

And as you have already seen form above the context of the function is the droppable element and the parameter is the draggable.

Last but not least, if you are wondering how this JavaScript function is being used with the ASP.NET MVC wrappers, the MVC side property accepts a string with the function’s name. What that means is that such functions need to be discoverable on the global scope (on window really), so be careful where you define it:

  //rest is omitted
    }).DragAndDropSettings(d =>
    {
        d.ExpandDelay(500);
        d.CustomDropValidation("customValidation");
    })
 

And then:

<script>

    function customValidation(element) {

        // omitted

    }

</script>

Resources

First let me again remind of the elaborate Ignite UI Tree Documentation and jQuery API Reference. Then don’t forget the awesome samples!

This time I’ll add in the mix a solid ASP.NET MVC demo project ( with everything from here included in with both MVC helper and script-only demos, plus some basic stuff from the previous post). Make sure to check that one out, the animations above don’t do it justice! You would need at least a trial version of Ignite UI so hit the banner below if you are still lacking one.

Also you can go for fiddling with two demos on JSFiddle:

Stay tuned, for there is still more awesome tricks I have for you – next time we’ll do some updating support!

Summary

This was the second part of the in-depth look at the Ignite UI Tree’s Drag and Drop feature. We covered some of the challenges such functionality presents and how you can overcome them. We improved the selection handling of moved nodes, we made the experience a true joy with Load on Demand. We also gave a little attention to the custom validation function – what is it for, what to expect and what you can do with it. At the end of this, I would like to remind you that this has been a proof of the concept that the controls are flexible enough to let you mold them to your needs with little code and great impact!

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

Introducing ReportPlus: Building Enterprise Dashboards on the iPad

glopez@infragistics.com — Wed, 19 Sep 2012 15:53:00 GMT

A long time ago, in a galaxy far far away we set out to build a solution that would challenge in some way the current status quo in the mobile business intelligence segment that treats the iPad pretty much as a one-way, consuming only experience, as a second class citizen.

In a time where mobile devices are becoming more and more capable we tried to envision how any power user could generate business intelligence insights based only on his iPad, assuming availability of any of an array of popular enterprise technologies, and relying as little as possible on any IT intervention for his self service BI journey to be a success.

Such a solution would enable anyone in the organization with an iPad, to be able to access LOB data, stored for instance in a SharePoint library, or a SQL Server database, or a Reporting Services report, even an Analysis Services cube, without the hassle of going through any additional server side setup or configuration. The premise is simple, if the user has clearance, then he should be able to access enterprise data from the iPad, no excuses.

Additionally, this solution would allow him to filter & pivot that information, customizing the way it’s presented, allowing charting options, and composing all views in meaningful dashboards, that he could share. Since that authoring experience would be completely based on the iPad, all the interactions of the process would have to accommodate to a gesture based experience, so it should be a tap and drag driven interaction. The goal would be to provide the most simple, and easy to use user experience possible.

So we’ve been working hard to make that vision a reality, and we are very pleased to announce that the result of that effort is already available for download. We call it ReportPlus, you can check it out in the iTunes app store.

For more information, check this ReportPlus Introductory video, and Craig's post on the subject.

jQuery Mobile Controls by Infragistics

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

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

Enter the Infragistics jQuery Mobile controls

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

The List view

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

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

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

The Rating

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

Style

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

A Mobile App

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

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

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

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

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

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

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

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

Wrapping Up

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

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

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

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.

Getting Started with igGrid, OData, and WCF Data Services

amarisi — Thu, 28 Jul 2011 18:54:00 GMT

The igGrid is a client-side data grid with paging, filtering, and sorting functionality. It can bind to local data including XML, JSON, JavaScript arrays, HTML tables and remote data returned through web services.

The most seamless way to bind the igGrid to remote data is to use it in conjunction with OData. OData, or Open Data Protocol, operates over HTTP and provides a means of querying and updating data in JSON and AtomPub formats through a set of common URL conventions. This means that you can provide the grid with a URL to the OData service, set one property, and all of the paging, filtering, and sorting can be done remotely on the server without any additional configuration.

This article shows how to setup a client-side jQuery grid with remote paging, filtering, and sorting by setting up a WCF Data Service in an ASP.NET Web Application and setting two options on the igGrid.

1. Open Visual Studio and create a new ASP.NET Empty Web Application called ‘igDataSourceWCFService’:

Note: this is a plain old ASP.NET Web Application – this is not ASP.NET MVC. NetAdvantage for jQuery is ‘server agnostic’, meaning it does not rely on any specific server-side architecture. While the product ships with built-in support for ASP.NET MVC, this server framework is not required to use the rich client-side functionality.

2. Add an App_Data folder to your project and add the AdventureWorks database into that folder:

Note: To obtain the AdventureWorks database, download it here.

3. Next, add an ADO.NET Entity Data Model named AdventureWorksEntities.edmx to the project and point it to the AdventureWorks database:

4. Choose the Product table to be included in the Entity Data Model:

5. Next add a WCF Data Service to the project named ‘AdventureWorksService.svc’:

6. At this point your project should look like this:

7. Next, open the ‘AdventureWorksDataService’. This class derives from DataService<T> where T has not yet been defined. Specify the type of your Entity Data Model here:

public class AdventureWorksDataService : DataService<AdventureWorksLT2008_DataEntities>

8. Next, enable access to the Products table through the Data Service by adding this line of code within the InitializeService method:

public static void InitializeService(DataServiceConfiguration config
{
	config.SetEntitySetAccessRule("Products", EntitySetRights.AllRead);
	config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
}

9. WCF Data Services has native support for the Atom format. To enable JSON formatted data, you should download the JSONPSupportBehavior code file and include it in your application.

10. Once the JSONPSupportBehavior.cs file is included in your application, make sure to change the namespace to match the namespace used in your application. Also, add the JSONPSupportBehavior attribute to your AdventureWorksDataService class:

[JSONPSupportBehavior]
public class AdventureWorksDataService : DataService<AdventureWorksLT2008_DataEntities>

11. At this point, you can run the Web Application and access the data of the service so now it’s time to setup the igGrid.

12. You will need the NetAdvantage for jQuery combined and minified script file, ig.ui.min.js, which comes with the product. In addition, you will need the jQuery, jQuery UI, and jQuery templates scripts to run the sample. This help article discusses referencing the required scripts and where the combined and minified scripts can be found.

Note: You can download the full or trial product here. The jQuery templates script can be obtained here.

13. You should setup a scripts directory in your project and copy the JavaScript files into this folder.

14. Setup a styles directory and add the Infragistics themes directory to this folder. For more information on working with the jQuery themes for the igGrid, see this help topic.

15. Next you can setup the sample page. You are going to add a new html page to the application and call it ‘default.htm’. Once that is done your project will look like this:

16. Open the default.htm file and include CSS links and script tags for the jQuery resources:

<head>
    <link href="styles/themes/min/ig/jquery.ui.custom.min.css" rel="stylesheet" type="text/css" />
    <link href="styles/themes/base/ig.ui.min.css" rel="stylesheet" type="text/css" />
 
    <script src="scripts/jquery.min.js" type="text/javascript"></script>
    <script src="scripts/jquery-ui.min.js" type="text/javascript"></script>
    <script src="scripts/jquery.tmpl.min.js" type="text/javascript"></script>
    <script src="scripts/ig.ui.min.js" type="text/javascript"></script>
</head>

17. Next, add a TABLE element to the body of the HTML which will serve as the base element for the grid:

<body>
	<table id='tableProducts'></table>
</body>

18. Add another script tag to the HEAD and instantiate an igGrid and define columns:

<script type="text/javascript">
        
$(window).load(function () {
	$('#tableProducts').igGrid({
		height: '500px',
		width: '800px',
		autoGenerateColumns: false,
		columns: [
			{ headerText: 'ID', key: 'ProductID', dataType: 'number' },                
			{ headerText: 'Name', key: 'Name', dataType: 'string' },                
			{ headerText: 'Number', key: 'ProductNumber', dataType: 'string' },                
			{ headerText: 'Cost', key: 'StandardCost', dataType: 'number', format: 'currency'}
		]
	});
});
</script>

19. To bind the igGrid to data, two options should be set to define the URL for the data and the responseDataKey:

Note: The value d.results is a standard response key for JSON data coming from a ‘V2’ OData service

responseDataKey: 'd.results',
dataSource: 'AdventureWorksDataService.svc/Products?$format=json',

20. Finally, enable the features of the grid including the option to make them operate remotely:

features: [
	{
		name: 'Selection',
		mode: 'row',
		multipleSelection: true
	},
	{
		name: 'Paging',
		type: 'remote',
		pageSize: 15
	},
	{
		name: 'Sorting',
		type: 'remote'
	},
	{
		name: 'Filtering',
		type: 'remote',
		mode: 'advanced'                                    
	}
]

Run the sample and you will see the igGrid rendered. Combined with OData, the grid can filter, sort, and page data remotely by supplying a single URL as the datasource.

Download Sample

Note: The AdventureWorks database and NetAdvantage for jQuery resources are not included in the sample. Visit these links to obtain the software:

AdventureWorks Database

NetAdvantage for jQuery

Search results matching tag 'OData'

Tips on Drag & Drop with the Ignite UI Tree

Play nice?

Play nice.. or I’ll make you!

Load on Demand

A word on the custom validation function

<script> function customValidation(element) { // omitted } </script>

Resources

Summary

Introducing ReportPlus: Building Enterprise Dashboards on the iPad

jQuery Mobile Controls by Infragistics

Enter the Infragistics jQuery Mobile controls

A Mobile App

Wrapping Up

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

Introduction

Getting started

Results

Conclusion

jQuery Hierarchical Grid - Load On Demand

Load on Demand with jQuery

Load On Demand with ASP.NET MVC

Events

The Added benefits

Conclusion

Getting Started with igGrid, OData, and WCF Data Services

<script>

function customValidation(element) {

// omitted

}

</script>