Search results matching tag 'Templating'

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!

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!

IgniteUI jQuery Grid Unbound Columns: Updating and Hierarchy

dpetev — Fri, 26 Oct 2012 23:01:00 GMT

Unbound Columns bring you the freedom of flexible layouts in the IgniteUI Grid and neat support for features to make your grid behave like nothing’s that different. After you’ve seen some of the capabilities (getting started blog) and inner workings(configure and make the most of it) it’s only natural to tackle some not too basic cases. We’ll throw in some editing action – in all fairness, something very basic as far as the user or desired end-result are concerned, however nothing simple in the eyes of the developer. Following that some curious scenarios when using the Hierarchical Grid with unbound columns. So let’s jump right on topic.

To Save or not to Save

Custom Deserialization

Adding Updating should be fairly straight-forward, but there’s a catch.. or rather a few. One thing you are extremely likely to face is handling updates to the server. The grid will behave as expected and kindly include unbound values in the transactions. For that reason, as we already mentioned. the client-side model that includes Unbound columns would not match the one the grid was bound to on the server. That means direct deserialization using the standard .NET serializators won't go very well(more like at all) and the same goes for using the Grid model's LoadTransactions method(which is the same thing really). The most reasonable way to go about this is custom deserialization. Don’t let that fool you – it’s actually very easy with something like Json.NET. Plus, it even comes pre-packed with some (all?) new MVC4 templates anyway. It’s fast and, as far as my experience goes, it handles missing or extra values easily. Let’s have the following Grid configuration with AdventureWorks () Employees similar to so far used examples:

 $('#grid').igGrid({
    updateUrl : '/Home/UpdateUrl',
    localSchemaTransform : false,
    autoGenerateColumns : false,
    autoGenerateLayouts : false,        
    primaryKey: "BusinessEntityID",
    columns : [{
            key : 'BusinessEntityID',
            dataType : 'number',
            headerText : 'B.E. Id'
        }, {
            unbound : true,
            key : 'name',
            headerText : 'Name',
            dataType : 'string'
        }, {
            key : 'LoginID',
            dataType : 'string',
            headerText : 'Login Id'
        }, {
            key : 'SickLeaveHours',
            dataType : 'number',
            headerText : 'Sick Leave Hours'
        }, {
            key : 'VacationHours',
            dataType : 'number',
            headerText : 'Vacation Hours'
        }, {
            unbound : true,
            key : 'total',
            headerText : 'Total',
            dataType : 'number',
            formula : calcTotal,
            template : '<span {{if parseInt(${total})/100 > 1 }} class=\'red\' {{/if}}> ${total} / 100 </span>'
        }
    ],
    features : [{
            name : 'Updating',
            enableAddRow : false,
            columnSettings : [{
                    columnKey : 'total',
                    readOnly : true
                }, {
                    columnKey : 'BusinessEntityID',
                    readOnly : true
                }]
        }
    ],
    height : '600px',
    dataSource : "@Url.Action("HrcEmployees")",
    rendered: function (evt, ui){
        ui.owner.setUnboundValues(peopleNames , "name");
    }
});
 

Or the equivalent in ASP.NET MVC using the helper with chaining:

 @(Html.Infragistics().Grid(Model).AutoGenerateColumns(false).AutoGenerateLayouts(true)
    .PrimaryKey("BusinessEntityID")
    .Columns(column =>
    {
        column.For(x => x.BusinessEntityID).HeaderText("B.E. Id").DataType("number");
        column.Unbound("name").HeaderText("Name").DataType("string");
        column.For(x => x.LoginID).HeaderText("Login Id").DataType("string");
        column.For(x => x.SickLeaveHours).HeaderText("Sick Leave Hours").DataType("number");
        column.For(x => x.VacationHours).HeaderText("Vacation Hours").DataType("number");
        column.Unbound("total").HeaderText("Total").DataType("number")
            .Formula("calcTotal").Template("<span {{if parseInt(${total})/100 > 1 }} class='red' {{/if}}> ${total} / 100 </span>");
    })
    .Height("600px")
    .Features(feature => 
        {
            feature.Updating().EnableAddRow(false).ColumnSettings(colSetting =>
            {
                colSetting.ColumnSetting().ColumnKey("total").ReadOnly(true);
                colSetting.ColumnSetting().ColumnKey("BusinessEntityID").ReadOnly(true);
            }).EditMode(GridEditMode.Row);
        })
    .UpdateUrl(Url.Action("UpdateUrl"))
    .SetUnboundValues("name", (ViewBag.people as List<string>).Cast<object>().ToList())
    .DataBind()
    .Render()
)
 

As you can see the ID is not editable for obvious reasons and so is the formula field. What you would get from the grid as a transaction would contain all of the above properties. One approach would be to take advantage of the flexibility of Json.Net and go about it as you normally would:

 var transactions = JsonConvert.DeserializeObject<List<Transaction<EmployeeDTO>>>(Request.Form["ig_transactions"]);
 

Form there on it is identical to what you can find in the documentation on Batch Updating. Another take would be to go for LINQ to JSON instead and deserialize to JObject:

 var transactions = JsonConvert.DeserializeObject<List<Transaction<JObject>>>(Request.Form["ig_transactions"]);
 

An advantage you get is that if you like me don’t have the whole model displayed in the grid and therefore the transactions don’t contain quite the whole records and assigning it blindly will just put nulls in the ones I’m missing. Besides picking separate properties from the record this approach is also the easiest way to access unbound values if you need them:

 AdventureWorksEntities context = new AdventureWorksEntities();
foreach (Transaction<JObject> transaction in transactions)
{
    int id = (int)transaction.row["BusinessEntityID"];
    // take id in advance as accessing it is not a canonical method and then find the data records 
    var employee = context.Employees.Where(x => x.BusinessEntityID == id).Single();
    var person = context.People.Where(x => x.BusinessEntityID == id).Single();
    if (transaction.type == "row") //edit!
    {
        employee.VacationHours = (short)transaction.row["VacationHours"];
        employee.SickLeaveHours = (short)transaction.row["SickLeaveHours"];
        employee.LoginID = (string)transaction.row["LoginID"];
        person.FirstName = transaction.row["name"].ToString().Split(' ').First();
        person.LastName = transaction.row["name"].ToString().Split(' ').Last();
    }
    if (transaction.type == "delete") //delete!
    {
        context.Employees.DeleteObject(employee);
    }
}
context.SaveChanges();
 

“My Unbound values don’t reach the server”

So you use the client-side ‘setUnboundValues()’ method like you are supposed to and attempt to save the changes with the method above but they never appear to persist. What gives? Well, for starters “you are supposed to” in the last sentence is truly wrong – the method does set values but since it’s designed to work without updating on the grid, the changes it makes are “client-side only” type and are completely unrelated with Updating and transactions. That means that you are setting a value but it is never sent to the server or persisted in other way. So to achieve the desired result you should turn to the Updating API instead and use either ‘setCellValue’ or ‘updateRow’. Yes, they work work with Unbound columns! Frankly, the methods have very subtle differences with the main one being the type of transaction they generate and I usually pick the one that matches the edit mode:

 <button onclick="$('#grid').data('igGridUpdating').setCellValue(2, 'name', 'John Doe')"> Update names [cell]</button>
<button onclick="$('#grid').data('igGridUpdating').updateRow(2, { name : 'John Doe'})"> Update names [row]</button>
 

There basically produce the same result with different type of transaction. In the demo and the JFiddle versions linked below I’ve put up a simple demonstration of this with a log you can use to list the current transactions on the grid in order to see that there are indeed none after a ‘setUnboundValues()’ call but the Updating methods behave as expected.

Formula Trouble

So you save your changes and everything obviously goes well with the server, but ..

Find something wrong? This is a row in which I’ve edited the Vacation hours value, however the total value calculated from a formula stays the same and moreover, it’s the same after the actual submit of transaction to the server passes too. Because of the type of functionality formula property – it is neither a template nor a formatting function, it’s supposed to provide the initial value. Therefore, it’s called on binding and from there on the grid has data to work with as if it is part of the data source and formula is no longer needed. But hey, I want my value correct and I don’t feel like reloading the page for sure. So how do you get this to work? Consider this, the save changes method does not offer a callback and in case you are wondering neither does the original in the igDataSource. But it does say AJAX and it should have a callback, right? And it does, lets just say it’s well hidden. It’s called a success handler and the grid maintains an array of them to call when it handles the AJAX success (only!). Also the problem is I want to refresh my view in order to update the formula calculations. However, simply calling ‘dataBind()’ on the data source won’t do in my case as I have additional unbound values(the names) that are still the same and they won’t update until a refresh of the page. Plus, it's a lot of overhead I don't really need(goodness forbid using the grid's data bind method that does a whole lot more work even). Thankfully you have grid operations that cause a re-bind such as paging and sorting without messing with the actual data in the source. What if we could use that? Well we can! A slight hack if you will would be to trick the grid into changing page without actually changing it which would essentially be a page re-fresh. This can be done using the ‘pageIndex()’ data source method you'd normally use to programmatically change page or get current index:

 $("#grid").live("iggridrendered", function (event, ui) {
    //rendered event only fired once so add success update handler here
    ui.owner.dataSource._addChangesSuccessHandler(updateSuccess);
});
function updateSuccess(data, textStatus, jqXHR) {
    if (data.Success === true && textStatus == "success") {
        //'re-bind' to force formula calculation with new verified values.
        var gridDS = $("#grid").data("igGrid").dataSource;
        gridDS.pageIndex(gridDS.pageIndex());
    }
}
 

This registers your own handler that gets the very same parameters as a normal AXAJ callback (and this can be useful in many other scenarios!) and in it we access the grid’s data source now that we know that the save has gone through and do our little refresh inception-style. It’s not perfect, but it kind of works; another very plausible solution would be to just go ahead and set the right value.

NOTE: Keep in mind that if you use template to display value in unbound column that is built with values from other columns it will update once they change. There’s a demo available for that in both MVC and JFiddle below.

Hierarchical Grid with Unbound Columns

Now here’s another good one. By design the hierarchical grid uses flat igGrids and for that reason we consider most of the functionality to be shared and used in the same way with the same results. However, there are a few logical, yet important differences to consider when using hierarchy with Unbound Columns.

Setting values and child column layouts

Of course, all the methods to do that are still available, but consider this – you now have not just one grid, but rather a whole bunch of them. Using the ‘unboundValues’ is mostly logical as they are tied to their column definitions. But when you decide to set some unbound values on the client but nothing happens? For reference here’s how the grid definition looks:

 $('#grid').igHierarchicalGrid({
    dataSource: @Html.Raw(Json.Encode(Model)),
    dataSourceType: 'json',
    autoGenerateColumns: false,
    autoGenerateLayouts: false,
    columns: [{
        key: 'DepartmentID',
        headerText: 'DEP Id',
        dataType: 'number'
    }, {
        key: 'Name',
        headerText: 'Name',
        dataType: 'string'
    }, {
        key: 'GroupName',
        headerText: 'Group Name',
        dataType: 'string'
    }, {
        key: 'ModifiedDate',
        headerText: 'Modified Date',
        dataType: 'date'
    }, {
        unbound: true,
        key: 'employees',
        headerText: 'Employees',
        dataType: 'number',
        unboundValues: [7, 3, 18, 9, 12, 4, 180, 5, 6]
    }
],
    columnLayouts: [{
        autoGenerateColumns: false,
        autoGenerateLayouts: false,
        mergeUnboundColumns: true,
        columns: [{
            key: 'BusinessEntityID',
            headerText: 'B.E. Id',
            dataType: 'number'
        }, {
            key: 'DepartmentID',
            headerText: 'Dep id',
            dataType: 'number',
            hidden: true
        }, {
            unbound: true,
            key: 'name',
            headerText: 'name',
            dataType: 'string'
        }, {
            key: 'VacationHours',
            headerText: 'Vacation Hours',
            dataType: 'number'
        }, {
            key: 'SickLeaveHours',
            headerText: 'Sick Leave Hours',
            dataType: 'number'
        }, {
            unbound: true,
            key: 'counter',
            headerText: 'Counter',
            dataType: 'number'
        }
        ],
        key: 'Employees',
        primaryKey: 'BusinessEntityID',
        foreignKey: 'DepartmentID'
    }
],
    height: '500px',
    autoCommit: false,
    primaryKey: 'DepartmentID',
    localSchemaTransform: true
});
 

And to sill some of the missing values you attempt calling something like:

 $('#grid').igHierarchicalGrid('setUnboundValues', [ 52, 522, 368, 42635], 'counter');
 

However nothing happens. If you had attempted the same with say ‘employees’ it would’ve. That is because as we explained there are multiple grids here and set value methods are to be called for the respective layout. So in order to add values to the child layout you need to access it first. The hierarchical grid provides a method to do that:

 $.each($('#grid').data('igHierarchicalGrid').allChildrenWidgets(), function (i, grid) {
    grid.setUnboundValues([12.2, 12.2, 12.2, 12.2], 'counter');
});
 

You could pick one, but above I’m targeting all available child grids and setting values and there’s a good reason. To be able to target specific layout you need to be aware it is there – the Hierarchical grid creates the child grids only when expanding for performance reasons, therefore you cannot set values to something that doesn’t exist yet. Furthermore, unless you provide you unbound values in advance ( set them on the column property or merge them on the server) even after calling the above, newly expanded(created) layouts will still be with empty unbound columns. My best advice is to assign even temporary initial values to spare the user the sight of empty columns and/or handle a suitable event such as 'childGridCreated'.

ASP.NET MVC

MVC offers some additional challenges such as the relevant Merge Unbound Columns property and others. First and foremost let me remind again the SetUnboundValues’s Dictionary method overload is still your best bet to get things going as expected. Also the client-side explanations above still holds true although this time you set values to column layouts of the main grid, but it has to be done for the respective layout.

 childLayout.MergeUnboundColumns = true;
childLayout.Columns.Add(new UnboundColumn()
{
    Key = "counter",
    HeaderText = "Counter",
    DataType = "number",
    UnboundValues = new List<object>() { 1, 2, 3, 4, 5, 6, 7, 8, 9 }
}); //This will not work!
 

Using the Unbound values column property which if used in child layout definition will be applied to all layouts by default. However when you enable merging the values inside the column definition are not supported and pretty much ignored. So in their place you get the default null values and empty columns on the client.

Then you have the SetUnboundValues’s List overload that suspiciously looks very much like the property, but you will be surprised when it actually works with merging. But there’s also a catch – since the method’s purpose is to provide all values for for a grid in one go, when used it will still map values to ID’s ..of the first child layout only. This is as far as the grid is willing to do the guessing for you I guess. However if the child layout doesn’t have primary key another default behavior kicks in and those values are applied separately to each child. I’m only explaining all of this as I think in some situations child layouts could be sharing values or just need an example values for one layout and these can turn out just fine.

Once again, assigning with the Dictionary overload applies the required mapping so values will properly be added throughout children based on key matches.

Load On Demand and Merge Unbound columns don’t go well…

These really don’t go well at all! And it’s really not that surprising – LoadOnDemand assures the grid that data for child layouts will be provided later on and merging demands they are present in the data source, so even though you may have Unbound Values set using the property itself and you can see it on the client code it will still be ignored and data for the unbound columns will be required from the data received when creating the child. That mean that you need to send it along with the original grid model and this makes the Unbound Columns redundant or if the source is oData nearly absurd to implement. SO better don’t try this at home. The best part is that if you don’t provide those values and the grid starts looking for them it will end up badly..with exceptions :) This is true for SetUnboundValue methods as well, however this is not hopeless combination of functionality:

GetData() to the rescue

Of course, this is the Grid models’ GetData() method and it’s extremely helpful when using load on demand. In fact, so helpful, that when used to generate responses for the child layouts it will look at your model and properly merge unbound values applied with SetUnboundValue methods again following the default behavior – with list values are added to each generated response essentially added to very layout and with dictionary overload just the matching ones. So this (lines 73/74 in the model show the setting of values with both List and Dictionary):

 public JsonResult BindChild(string path, string layout)
{
    GridModel viewModel = GenerateGridModel();
    AdventureWorksEntities context = new AdventureWorksEntities();
    viewModel.DataSource = context.Employees.ToList().ConvertAll(eh => eh.ToDTO()).AsQueryable();
    return viewModel.GetData(path, layout);
}   
 
private GridModel GenerateGridModel()
{
    GridModel grid = new GridModel();
    grid.Height = "500px";
    grid.AutoCommit = false;
    grid.PrimaryKey = "DepartmentID";
   
    grid.AutoGenerateColumns = false;
    grid.AutoGenerateLayouts = false;
    GridColumnLayoutModel childLayout = new GridColumnLayoutModel();
 
    //settings
    grid.LoadOnDemand = true;
    childLayout.Key = "Employees";
    childLayout.PrimaryKey = "BusinessEntityID";
    childLayout.ForeignKey = "DepartmentID";
    childLayout.MergeUnboundColumns = true;
    
    childLayout.AutoGenerateColumns = false;
    childLayout.AutoGenerateLayouts = false;
 
    childLayout.DataSourceUrl = Url.Action("BindChild");
 
    childLayout.Columns = new List<GridColumn>();
    childLayout.Columns.Add(new GridColumn()
    {
        Key = "BusinessEntityID",
        HeaderText = "B.E. Id",
        DataType = "number"
    });
 
    childLayout.Columns.Add(new GridColumn()
    {
        Key = "DepartmentID",
        HeaderText = "Dep id",
        DataType = "number",
        Hidden = true
    });
 
    childLayout.Columns.Add(new UnboundColumn()
    {
        Key = "name",
        HeaderText = "name",
        DataType = "string",
    });
 
    childLayout.Columns.Add(new GridColumn()
    {
        Key = "VacationHours",
        HeaderText = "Vacation Hours",
        DataType = "number"
    });
    childLayout.Columns.Add(new GridColumn()
    {
        Key = "SickLeaveHours",
        HeaderText = "Sick Leave Hours",
        DataType = "number"
    });
    childLayout.Columns.Add(new UnboundColumn()
    {
        Key = "counter",
        HeaderText = "Counter",
        DataType = "number"
    });
    childLayout.SetUnboundValues("counter", new List<object>() { 1, 2, 3, 4, 5, 6, 7, 8, 9 });
    childLayout.SetUnboundValues("name", peopleNames);
 
    grid.Columns = new List<GridColumn>();
    grid.Columns.Add(new GridColumn()
    {
        Key = "DepartmentID",
        HeaderText = "DEP Id",
        DataType = "number"
    });
    grid.Columns.Add(new GridColumn()
    {
        Key = "Name",
        HeaderText = "Name",
        DataType = "string"
    });
 
    grid.Columns.Add(new GridColumn()
    {
        Key = "GroupName",
        HeaderText = "Group Name",
        DataType = "string"
    });
 
    grid.Columns.Add(new GridColumn()
    {
        Key = "ModifiedDate",
        HeaderText = "Modified Date",
        DataType = "date"
    });
    grid.Columns.Add(new UnboundColumn()
    {
        Key = "employees",
        HeaderText = "Employees",
        DataType = "number",
        UnboundValues = new List<object>() { 7, 3, 18, 9, 12, 4, 180, 5, 6 }
    });
 
    grid.ColumnLayouts.Add(childLayout);
    return grid;
}
 

Will produce the following response to the client:

 {
    "Records" : [{
            "BusinessEntityID" : 11,
            "DepartmentID" : 2,
            "name" : "Ovidiu Cracium",
            "VacationHours" : 7,
            "SickLeaveHours" : 23,
            "counter" : 1
        }, {
            "BusinessEntityID" : 12,
            "DepartmentID" : 2,
            "name" : "Thierry D\u0027Hers",
            "VacationHours" : 9,
            "SickLeaveHours" : 24,
            "counter" : 2
        }, {
            "BusinessEntityID" : 13,
            "DepartmentID" : 2,
            "name" : "Janice Galvin",
            "VacationHours" : 8,
            "SickLeaveHours" : 24,
            "counter" : 3
        }
    ],
    "TotalRecordsCount" : 0,
    "Metadata" : {
        "timezoneOffset" : 10800000
    }
}
 

Even when merging is not in use, this method will be kind enough to include the said values as metadata instead and achieve the same results. One thing to note is that the method does require the presence of primary and foreign key in the child layout in order to perform proper mapping, which if not needed can be hidden but still must be present. Despite that, using the Grid model with Load On demand is the best way to have child data generated properly and it allows Unbound Columns to be merged along with all else!

Bonus scene (formula + template)

Or more like bonus scenario. Since unbound columns are not even tied with values what happens if as above and examples before you got that Unbound Column with both formula to calculate total and template. Now that template uses a static value for the max…how about we add yet another column for that, provide some values and use that instead in the template?

 @(Html.Infragistics().Grid(Model).AutoGenerateColumns(false).AutoGenerateLayouts(false).LocalSchemaTransform(false)
    .ColumnLayouts(layout => layout.For(x => x.Employees).AutoGenerateColumns(false).Columns(column =>
        {
            column.For(x => x.BusinessEntityID).HeaderText("B.E. Id").DataType("number");
            column.For(x => x.SickLeaveHours).HeaderText("Sick Leave Hours").DataType("number");
            column.For(x => x.VacationHours).HeaderText("Vacation Hours").DataType("number");
            column.Unbound("total").HeaderText("Total / Max").DataType("number").Formula("calcTotal").Template("<span {{if ${total}/parseInt(${max}) > 1 }} class='red' {{/if}}> ${total} / ${max} </span>");
            column.Unbound("max").HeaderText("Max").DataType("string").Hidden(true);
        })
        .LocalSchemaTransform(false)
        .SetUnboundValues("max", new Dictionary<object, object>() { { 2, 50 }, { 3, 100 }, { 5, 80 }, { 6, 100 }, { 11, 25 }, { 12, 66 }, { 13, 76 }, { 4, 32 }, { 15, 18 } })
        .PrimaryKey("BusinessEntityID")
    )
    .PrimaryKey("DepartmentID")
    .Columns(column =>
    {
        column.For(x => x.DepartmentID).HeaderText("DEP Id").DataType("number");
        column.For(x => x.Name).HeaderText("Name").DataType("string");
        column.For(x => x.GroupName).HeaderText("Group Name").DataType("string");
        column.For(x => x.ModifiedDate).HeaderText("Modified Date").DataType("date");
        column.Unbound("employees").HeaderText("Employees").DataType("number").UnboundValues(new List<object>() { 7, 3, 18, 9, 12, 4, 180, 5, 6 });
    })
    .Height("600px")
    .Features(feature => 
        {
            feature.Paging().Type(OpType.Local).PageSize(10);
            feature.Sorting().Type(OpType.Local);
            feature.Filtering().Type(OpType.Local);
        })
    .DataSource(Model)
    .ClientDataSourceType(ClientDataSourceType.JSON)
    .DataBind()
    .Render()
)
 

Would it work as expected? For a moment, it might. See there’s no merging enabled, therefore it happens on the client and since the schema doesn't include the Unbound columns the grid isn’t as kind as to go about and apply null-s to every record missing unbound value. So in essence unless you provide all of them, records will not even have a ‘max’ property and guess what happens when the templating engine tries to get a value for it :) But no worries, a solution is possible using yet another formula:

 column.Unbound("max").HeaderText("Max").DataType("string").Hidden(true).Formula("maxFix");
 

And in it you can assign values or in this case keep the ones available and place defaults. It doesn’t even have to be null-s anymore:

 function maxFix(row, grid) {
    return row.max ?   row.max : "???";
};
 

And you get quite lovely results:

Resources and demos

How to get started with jQuery Grid Unbound Columns
- Why Unbound columns?
- Quick setup + with ASP.NET MVC wrapper
- Adding data: with the UnboundValues property, Set Unbound Values methods and calculating them via formula.

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

You can instantly try the the feature with the following JSFiddle-s:

I’ve prepared a fairly elaborate ASP.NET MVC project with various grid configurations described above with both jQuery/JavaScript and MVC Helper. Keep in mind most views use the MVC wrapper and require at least a trial version of Ignite UI on your machine – click the banner below to get yourself one.
There are two demos available in our Samples: Unbound Column in the Grid and Unbound Column in the Hierarchical Grid.
You can find general and control specific help in our Online Documentation
You can find the client-side options and methods in the Ignite UI jQuery Grid API reference.

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

TL;DR | Summary

In this article we covered the usage the Updating feature with Unbound Columns in the IgniteUI Grid – how to deserialize the now non-conforming model of data the client side jQuery widget is sending. We also looked into the proper methods of setting values so they can be persisted and how to deal with editing and formula updating upon dependency field change.

In addition to those, some light was shone upon how the Hierarchical version of the grid ever so slightly differs from the flat one and the unique challenges it poses – setting values and the dynamic creation of child widgets. The odd interaction between options such as Merge Unbound columns and Load on Demand and just how bad can things so and how useful the ASP.NET MVC Grid model ‘GetData()’ method can be to prevent that. Lastly, a small demo just to give head up when using Unbound Column values in templates without merging values on the server.

jQuery Grid Unbound Column: How to make the most of it

dpetev — Tue, 16 Oct 2012 21:39:00 GMT

When in need of displaying columns with separate data – be it from a different source or based on the values of others – this new column type will prove truly helpful. Be sure to read the introductory blog on how to get started with jQuery Grid Unbound Columns. As promised we’ll go into greater detail into the options available to tweak the Ignite UI Grid’s Unbound Column feature to your own use case and needs.

Merge Unbound Columns

This is where it really gets interesting. Due to the very nature of the performed functions – bringing two or more distinct sources together in a single control’s view - as a developer you are given a additional option to control that. You can define the grid’s behavior using the MergeUnboundColumns property. It is relevant when defining a grid on the server-side with the ASP.NET MVC wrapper. The default option is false and what happens is that your unbound values get sent to the client as Metadata, rather than along with the actual data source records. You can take for example the previous blog sample. To make it clear here is how a part of the grid definition would look with the option off by default :

(It’s a little bit formatted and the actual records are collapsed so the structure can be visible, but rest assured they do not contain any of the unbound values)

Of course, if you take a closer look at the generated scripts you will also notice the above grid being initialized with the identical client property ‘mergeUnboundColumns’ being false. I did say it was a property meaningful when using the ASP.NET MVC helpers and it mostly is. What the client property does is being a flag for the grid if the data comes merged..or should the control do that on the client-side only in combination with remote data source. Otherwise, this property with local source won’t have any effect whatsoever. What all this means is that at the end of the journey the widget will have to do the merging anyway – that is how such values can normally participate in features such as sorting, filtering, etc.

Naturally, what makes the difference when setting this property to true is that the merging is performed on the server. Notice line 2 below:

 @(Html.Infragistics().Grid(Model).AutoGenerateColumns(false).AutoGenerateLayouts(true)
    .MergeUnboundColumns(true)
    .Columns(column =>
    {
        column.For(x => x.BusinessEntityID).HeaderText("B.E. Id").DataType("number");
        column.Unbound("name").HeaderText("Name").DataType("string");
        column.For(x => x.LoginID).HeaderText("Login Id").DataType("string");
        column.For(x => x.SickLeaveHours).HeaderText("Sick Leave Hours").DataType("number");
        column.For(x => x.VacationHours).HeaderText("Vacation Hours").DataType("number");
    })
    .Height("600px")
    .Features(feature => 
        {
            feature.Paging().Type(OpType.Local);
            feature.Sorting().Type(OpType.Local);
            feature.Filtering().Type(OpType.Local);
            feature.GroupBy().Type(OpType.Local);
        })
    .SetUnboundValues("name", (ViewBag.people as List<string>).Cast<object>().ToList())
    .DataBind()
    .Render()
)
 

As a result data gets send as a totally normal set of records and the merge client property states true telling the widget not to look for values in the metadata as they are no longer there:

Merged Unbound columns distinctive property – unboundDS

The “unboundDS” property indicates that the column is indeed unbound. This is done, regardless of the client treating unbound columns as bound when ‘mergeUnboundColumns’ is true. Or should I say this is done exactly because of that. Have a look at what comes as a column definition in this case:

 {
                unbound : false,
                key : 'name',
                headerText : 'Name',
                dataType : 'string',
                unboundDS : true
            }
 

As the values for the column are already in the records the grid is not supposed to look for them elsewhere and the unbound setting is false. But then again the same false can be added to any other column with no side effects..So how do you know if there are actual unbound columns defined anyway? This is why the ‘unboundDS’ property is here for, to give a way for a client code to know if and which columns’ values are separate and most importantly to inform the grid that remote operations such as filtering and sorting (not supported by the feature) should not be allowed for that column.

Performance

As you can see the above-described configuration produces mostly the same results, however this time the served had to do the heavy lifting and the client enjoys not having anything to do with this and being blissfully unaware of unbound values. This is also very important as you have the option to distribute the load between client and server. Then again a fair warning follows – merging on either side may result in a performance hit if the original data source is way too big. This is because the whole data must be traversed and new unbound values added to it (or default null values if the list values are less). As you can imagine though, the server is usually the one is a more dangerous position as the large data manipulations can become pretty a serious problem when they have to be performed multiple times for multiple clients. A client doing this instead should take much less of an impact doing just its own work.

On a side note, remember the Set Unbound Values methods discussed in the previous blog and how it is strongly advisable to use the Dictionary overload as it is a performance gain? Well it’s even more true when using the merge option on the server - causes even more work as the server will be otherwise forced to create the bindings between values you provide and primary keys available. Of course, you are best to save it the trouble and assign them yourself, plus that way the order of the values won’t matter as much.

Client-side data manipulation

Last time we demonstrated the client-side version of the method to set unbound values and saw the additional route of applying a formula on the client. However, those are not the only ways to set unbound values. There’s also an interesting turn of events regarding the usage of the so far described merge functionality that requires some additional client work and therefore, being well equipped to manipulate data on the client is never a bad thing.

Merging Unbound Columns and setting values on data-bound client event

Let’s have an identical example as so far but this time lets enable the merge option along with using the formula field from last time. Nothing special it shouldn’t affect the end result, right?

 @(Html.Infragistics().Grid(Model).AutoGenerateColumns(false).AutoGenerateLayouts(true)
    .MergeUnboundColumns(true)
    .Columns(column =>
    {
        column.For(x => x.BusinessEntityID).HeaderText("B.E. Id").DataType("number");
        column.Unbound("name").HeaderText("Name").DataType("string");
        column.For(x => x.LoginID).HeaderText("Login Id").DataType("string");
        column.For(x => x.SickLeaveHours).HeaderText("Sick Leave Hours").DataType("number");
        column.For(x => x.VacationHours).HeaderText("Vacation Hours").DataType("number");
        column.Unbound("total").HeaderText("Total").DataType("number").Formula("calcTotal");
    })
    .Height("600px")
    .Features(feature => 
        {
            feature.Paging().Type(OpType.Local);
            feature.Sorting().Type(OpType.Local);
            feature.Filtering().Type(OpType.Local);
            feature.GroupBy().Type(OpType.Local);
        })
    .SetUnboundValues("name", (ViewBag.people as List<string>).Cast<object>().ToList())
    .DataBind()
    .Render()
)
 

Well it did…

See when merge is enabled essentially you tell the grid values will be provided on/from the server and a JavaScript function for the formula is definitely not that. Also since as I explained values are assigned with null as default… that is what you end up getting this way. Can you still provide the same functionality with merged unbound columns? Sure! It’s not quite as simple, but possibly the most appropriate way to do this is to handle the client ‘dataBound’ event, at which point will have the data source object ready and you can directly assign values for unbound columns. Here’s the old formula function:

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

All that’s different is that you don’t have a function called each time with row values, but you can make it work again(if it was something big that you would not want to change or refactor):

 $("#Grid1").live("iggriddatabound", function (evt, ui) {
   // ui.owner is a reference to the actual grid widget
    var data = ui.owner.dataSource.data();
    $.each(data, function (index, record) {
        var unboundValue = calcTotal(record, ui.owner);
        record["total"] = unboundValue;
    });
});
 

Once more, the data-bound event is the most logical place to execute that code as you have the data source, but the UI is not yet rendered, therefore this solution creates exactly the same results as before without noticeable difference for the end-user. Even so, it’s worth mentioning that you can enforce this method of assigning unbound values directly into the source at any point after this as an alternative to the SetUnboundValues method.

Get them!

Speaking of ‘SetUnboundValues ‘ the opposite operation is also available as a client method. There’s also a method to get the whole column even:

 var unboundColumn = $('#grid1').igGrid('getUnboundColumnByKey', 'name');
var unboundValues = $('#grid1').igGrid('getUnboundValues', 'total');
 

The first provides you with the whole column with it’s properties and values:

And the values only method will give you just that array of values, however the column key parameter is optional and if not defined an object with all unbound columns’ value arrays will be returned instead.

It’s Complicated

Or is it? There are a number of questions in regard to what happens with unbound columns and advanced column features you’d normally use. This is especially true when you have a formula defined as well… well you can rest assured the functionality is all there. In the very special case of formula calculations to get the value – it is called before any formatting function or applying a template so for all intents and purposes it will work as with any other column. Just the column definition:

 column.Unbound("total").HeaderText("Total").DataType("number").Formula("calcTotal").Template("<span {{if parseInt(${total})/100 > 1 }} class='red' {{/if}}> ${total} / 100 </span>");
 

And it’s all working pretty well:

Same goes for formatter functions that are the more extended functionality, but largely similar to templating.

Resources and demos

How to get started with jQuery Grid Unbound Columns
- Why Unbound columns?
- Quick setup + with ASP.NET MVC wrapper
- Adding data: with the UnboundValues property, Set Unbound Values methods and calculating them via formula.
Two JSFiddle-s available for you to play with – the previous one and another built on top with added support for getting unbound values from columns and conditional templating discussed in this blog.
A shared demo for this and the previous blog – and ASP.NET MVC project with various grid configurations described so far. Keep in mind most views use the MVC wrapper and require at least a trial version of Ignite UI on your machine – click the banner below to get yourself one.
There are two demos available in our Samples: Unbound Column in the Grid and Unbound Column in the Hierarchical Grid.
You can find general and control specific help in our Online Documentation
You can find the client-side options and methods in the Ignite UI jQuery Grid API reference.

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

TL;DR | Summary

In this article we covered the usage of the Merge Unbound Columns property and its vary important performance implications. A look at the inner workings of the grid’s server model provided some insight on what’s really happening and how that would affect your application. Furthermore, we saw how the merge can affect functionality such as the formula and how to overcome that, along with some additional client-side manipulation. Hopefully the blog also cleared any possible questions as to whether Unbound columns work well with other Ignite UI Grid column options such as formatter functions or templates.

I’ll end this in a manner similar to how it was started – saying that such a feature concerning something as underlying as columns types in the jQuery Grid can affect multiple behaviors and features and is by a long shot not a simple functionality, as I hope it has been made clear by now. For that reason, there are still more interesting topics to be discussed for the future.

jQuery Grid Checkbox Column alternatives (continue)

dpetev — Mon, 13 Aug 2012 14:40:00 GMT

This is the second part covering the topic of jQuery Grid checkbox column alternatives and/or custom implementations. A quick recap: the Checkbox column is a feature that provides default setup to turn Boolean values in the jQuery grid into checkboxes. As I explained, however, defaults are never good enough for every scenario out there and the community brought up the limitation it has regarding coexistence with column and row templates. While there are valid reasons for that, there are also plenty of cases where you want to go:

Well, you are not seeing wrong – it does look essentially the same. It’s very simple really. Say, if an application has been using the checkboxes so far and (as it always happens) an idea emerges to add some additional functionality over existing/new column that requires using a template. So it’s reasonable to want keep the same UI as before, right?

Furthermore, as you may remember from the first blog, I don’t quite enjoy the looks on the default checkbox and god forbid the user is running some other OS… Now these checkboxes look just fantastic, so let’s see how we can use those instead.

The Checkbox column feature to the rescue!

Not seeing wrong again – what I realized while creating the input templates is that the default feature itself is one as well! The feature being there, the styles and other useful bits are there for us to put together as we see fit. With that said, the first and the easiest thing to reuse is the checkbox column template and its styles.

The template

That template uses styled HTML Span tags along with CSS to create that UI element, which means it is completely open for styling and independent of OS or browser implementation. Here’s how a template like that would look like:

 var checkboxTemplate = "<span style=\"width:100%;display:inline-block;overflow:hidden;text-align:center;\">" + 
    "<span class=\"ui-state-default ui-corner-all ui-igcheckbox-small\">" + 
    "<span class=\"ui-icon ui-icon-check ui-igcheckbox-small-{{if ${SalariedFlag} === \"true\"}}on{{else}}off{{/if}}\"/>" + 
    "</span></span>";
 

Now the structure for the spans:

The outermost Span acts as a cell container spreading itself in the space available and allowing for the inner ones to be nicely centered. Optional.
The middle one acts as the checkbox border. Required.
The innermost is the empty/tick filling. The “ui-igcheckbox-small-off/on” are the respective styles. Note that the ‘off’ style overrides the ‘on’, so you can essentially have ‘on’ by default and add/remove ‘off’ as appropriate (that is exactly how it will be done later on). Also if you have noticed the ‘small’ component, there’s also a ‘normal’ version you can see in the Row Selectors feature. Required.

The result from this are not surprising (we were after those anyway). The best part is that you get the same look as before(if you have been using the feature), you get an UI control that looks much better than the default and even bleds with the style of other controls. Moreover, it does not only fit in style, it matches the style of the Row Selectors (which I view as essential is both are used) and it matches the theme, since the looks come from the CSS and it comes from the theme. A sample grid definition using the above:

 $.ig.loader(function () {
    $("#grid").igGrid({
        primaryKey: "BusinessEntityID",
        height: 550,
        dataSource: "@Url.Action("Employees")",
        autoGenerateColumns: false,
        columns: [
            { key: "BusinessEntityID", width: "50px", headerText: "ID", dataType: "number" , template: "<a href=\"http://msdn.microsoft.com/en-us/library/ms124432(v=sql.100).aspx\">${BusinessEntityID}</a>"},
            { key: "LoginID", width: "250px", headerText: "Login ID", dataType: "string" },
            { key: "JobTitle", width: "220px" , headerText: "Job Title", dataType: "string" },
            { key: "SalariedFlag", width: "120px", headerText: "SalariedFlag", dataType: "bool", template: checkboxTemplate },
            { key: "CurrentFlag", width: "100px",headerText: "Current Flag", dataType: "bool" , template: "<span style=\"width:100%;display:inline-block;overflow:hidden;text-align:center;\"><span class=\"ui-state-default ui-corner-all ui-igcheckbox-normal\"><span class=\"ui-icon ui-icon-check ui-igcheckbox-normal-on{{if ${CurrentFlag} === \"true\"}} {{else}} ui-igcheckbox-normal-off{{/if}}\"/></span></span>"}
             ],
        features: [
            { name: "Filtering", mode: "advanced", type: "local" },
            { name: "Sorting", type: "local" },
            { name: "Updating", editMode: 'none'}]
    });
});
 

The resulting grid with both small (default) checkboxes on the ‘Salaried’ column and ‘normal’ on the “Current Flag”:

And, yes, they go Metro or Modern UI (guess that is how it will be called now) if you apply the ‘metro’ theme:

As you can see since the values are Boolean the columns have no trouble with other Grid features.

One-click inline value updates

Of course, just like the previous solution you can hook up to the click event to handle user interaction without entering editing mode. Like before, using the Updating API will require the feature itself to be loaded and initialized with the grid (). This time, however we have two columns this time. The options are two – duplicate the event handler for each column or simply pass on the column key to the function and use that instead of static value:

 var checkboxTemplate = "<span style=\"width:100%;display:inline-block;overflow:hidden;text-align:center;\">" + 
    "<span class=\"ui-state-default ui-corner-all ui-igcheckbox-small\">" + 
    "<span class=\"ui-icon ui-icon-check ui-igcheckbox-small-{{if ${SalariedFlag} === \"true\"}}on{{else}}off{{/if}}\"" + 
    " data-rowid=\"${BusinessEntityID}\"  onclick=\"checkboxChanged(event, 'SalariedFlag');\"/></span></span>";
 

The ‘data-‘ attribute will be used to keep track of the row key and the column is passed to the handler. Some minor tweaks regarding the different availability of properties for browser support and the final snippet looks like this:

 function checkboxChanged(evt, colId) {
    // for IE < 9 currentTarget is srcElement
    var element = evt.currentTarget || evt.srcElement; 
    // get rowID where change occured:
    var rowId = $(element).data().rowid;
    var newValue;
    //IE doesn't have classList so check and use Name instead
    if (element.classList){
        newValue = element.classList.contains("ui-igcheckbox-small-on") ? false : true;
    }
    else{
        newValue = element.className.indexOf("ui-igcheckbox-small-on") >= 0 ? false : true;
    }
    $("#grid").igGridUpdating("setCellValue", rowId, colId, newValue);
}
 

The idea is very simple – if click has occurred it means the value should change and it should be the opposite of what it was right now – so we check if ‘on’ style is applied. Note, that I mentioned ‘off’ is the overwriting one, however in this case updating the cell value with an Updating method causes the UI to update and therefore the template is reapplied and the ‘on’ style won’t be there if the value is false.

Editing Action

There’s one more awesome part of the Checkbox column feature that can be reused. In the first blog I mentioned you can define your own Editor Provider. If you look up the Grid Updating API reference you can see a ‘columnSetting’ that allows to set an Editor Provider and it “should extend $.ig.EditorProviderDefault or it should have definitions of all its methods”. Now that can take some coding, but guess what – the Checkbox column already has one defined! So this is how you use it:

 $.ig.loader(function () {
    $("#grid").igGrid({
        primaryKey: "BusinessEntityID",
        height: 550,
        dataSource: "@Url.Action("Employees")",
        autoGenerateColumns: false,
        columns: [
            { key: "BusinessEntityID", width: "50px", headerText: "ID", dataType: "number" , template: "<a style=\"font-size:20px;\" href=\"http://msdn.microsoft.com/en-us/library/ms124432(v=sql.100).aspx\">${BusinessEntityID}</a>"},
            { key: "LoginID", width: "250px", headerText: "Login ID", dataType: "string" },
            { key: "JobTitle", width: "220px" , headerText: "Job Title", dataType: "string" },
            { key: "SalariedFlag", width: "150px", headerText: "SalariedFlag", dataType: "bool", template: checkboxTemplate}
        ],
        features: [
            { name: "Filtering", mode: "advanced", type: "local" },
            { name: "Sorting", type: "local" },
            { name: "Updating", columnSettings: [{ columnKey: "SalariedFlag", editorProvider: new $.ig.CustomEditorProviderCheckbox()} ]}]
    });
});
 

At line 16 – simple and very effective. Now when you enter edit mode you get a proper (and consistent) experience. And it’s really that simple:

Editor provider

The default provider shown above doesn’t quite meet the requirements? Then we’ll use a custom one and throw in some non-Boolean values in the mix for a good measure. As explained, you have a whole bunch of Editor provider for the needs of updating along with a default one that is recommended for customization. In our case, however, we can extend the checkbox provider instead and only implement the differences. Let me explain the basics of a provider – it’s a class with a few essential methods – one for creating an editor (this one gets called by Updating when edit mode gets activated and returns the actual editing element), one for getting and one for setting values. Then you have focus, size and validation managing, but those are implemented or don’t concern our type of provider. This is the basic flow of method execution to give you an idea why each method does what it does:

For example, if again you need to support values different than Boolean, you can use your template as usual and override the get and set value methods of the provider to have a nice checkbox editor as well – no read-only and no flicker. Plus it’s even quite easy to implement as well. For the case from the last blog and any other case of random ‘acceptable’ values and false equivalents means we don’t need to modify the setValue method as..well numbers and strings will evaluate as true and null-s will evaluate as false and it’ll work just fine to display the value in the editor. So it’s just the get and it’s almost amusingly easy:

 $.ig.CustomEditorProviderCheckbox = $.ig.CustomEditorProviderCheckbox || $.ig.EditorProviderCheckbox.extend({
    getValue: function () {
        return this.value ? 10 : null;
    }
});
 

Now say that those values won’t evaluate as expected (even though they currently do), you will have to also override the setValue and call the super-class’ method with the desired output:

 $.ig.CustomEditorProviderCheckbox = $.ig.CustomEditorProviderCheckbox || $.ig.EditorProviderCheckbox.extend({
    getValue: function () {
        return this.value ? 10 : null;
    },
    setValue: function (val, updating) {
      val = parseInt(val) ? true : false;
      this._super(val, updating);
    }
});
 

And if all that is not enough you can always go further – change the UI rendered for the Editor in the create method, change the way interaction affects the value in the set method and so on. But that’s a whole separate topic or more like a topic per type of provider as most of them have their special requirements and implementations.

The rest is pretty clear – same template style as in the ‘Editing Action’ part only with parseInt instead like in the previous blog. And again, using the column settings for Updating you set the provider of the desired column to be a new ‘$.ig.CustomEditorProviderCheckbox()’.

Comparison

PROS

Will work with other templates.
Easy to implement - 1 line for simple scenarios or one more to set the provider.
Consistent looks – fits with the rest of the grid parts and matches theme.
Excellent editing by reusing the default checkbox editor provider.
Again not limited to just Boolean values.
Also not limited to a bi-state checkbox, an tri-state checkbox can be potentially implemented()

CONS

Can require some code to implement with non-Boolean values, although as shown even there you can spare yourself most of the work.
Does require a little work to add that ‘single-click update’ functionality. I could argue it’s well worth it.
Nothing else I can see, really.

Conclusions

I hope this has been educational and occasionally useful. I also hope that it’s been made clear that defaults are not your only option and not only is it easy to create custom solutions but also recycling parts of available ones makes it that much better. The way the data is represented is completely arbitrary from the actual values and not only the good old forms elements or the modified ones with consistent looks can be used – at this point you can replace the checkbox with slider/toggle button and you can use similar approach to modify any other type of data representation. Because, in the end, the jQuery Grid and its features have proven to be very customizable and in most cases always have the right property, method or event to help a developer create awesome experiences!

Demo project is available for download. As always, you can follow us on Twitter @DamyanPetev and @Infragistics and stay in touch on Facebook, Google+ and LinkedIn!

jQuery Grid Checkbox Column alternatives

dpetev — Mon, 13 Aug 2012 07:16:00 GMT

The checkbox column (introduced with the last release, see this post on Using Checkbox Columns with the Infragistics jQuery Grid) was created to provide a ‘shortcut’ for transforming columns with Boolean values into checkboxes and mostly became reality due to the great interest in such functionality from customers (and after all it does make perfect sense).

Of course, this isn’t a perfect world and creating defaults that can fit everyone’s needs is probably a lost cause. If you take a look at the introductory blog above, it is indeed saving tons of time – setting a single property is all it takes. That’s good and all, but as it can even be seen in the comments there and on our forums ( this post for example) there is a limitation – the checkbox column works just great, but it goes all shy when some templating is involved.

The problem

In the Grid API reference under ‘renderCheckboxes’ it says “That option is not available when jQueryTemplating is used.” That’s just a slight bit misleading and is most certainly going to get updated, since this does, in fact, include our own Templating Engine. So in essence the above should be read as ‘That option is not available when Templating is used’. That is because, by design, the Checkbox column feature is suppressed in such cases, as a row template may have its own rendering for the column.

That may or may not be an intuitive explanation as to why it will not be available with column template as well, but once you think about it – the grid renders rows, it has a default template to do that – a row template. You defining a column simply ends up being included somewhere along the way in that row template, instead of the default. That is why, templating in general will disable this feature.

But not to worry, there are options as always. I stumbled upon this and since customer feedback pointed this out for us (Keep it up, we like constructive feedback!) in this blog I’ll share my experience with coming up for alternative ways to have such functionality.

A solution

Template Checkbox

Odd enough the problem is also main part of the solutions as it is the easiest way to alter the UI representation of your data and is also very flexible to be tweaked to your liking. Using this to add checkboxes in not all new () and as mentioned the feature itself is meant to be a shortcut for that.

A fair warning: I'm sharing my experience and because of that I’ll go through two different approaches I took. Before diving in using one, make sure you have seen and considered both.

So the first approach is to use a plain HTML input of type checkbox tag and assign it our value. This is the approach you can see in both forum posts linked above as well. You can apply the template to your row template (if you are already using one) or simple assign it to a single column. For demonstration purposes I’ll use the Employees table from AdventureWorks () for the Salaried flag column and here is how a grid configuration would look like:

 $("#grid").igGrid({
    primaryKey: "BusinessEntityID",
    height: 550,
    dataSource: "@Url.Action("Employees")",
    autoGenerateColumns: false,
    columns: [
        { key: "BusinessEntityID", width: "50px", headerText: "ID", dataType: "number" , template: "<a style=\"font-size:20px;\" href=\"http://msdn.microsoft.com/en-us/library/ms124432(v=sql.100).aspx\">${BusinessEntityID}</a>"},
        { key: "LoginID", width: "250px", headerText: "Login ID", dataType: "string" },
        { key: "JobTitle", width: "220px" , headerText: "Job Title", dataType: "string" },
        { key: "SalariedFlag", width: "120px", headerText: "SalariedFlag", dataType: "bool", template: "<input type=\"checkbox\" {{if ${SalariedFlag} === \"true\"}} checked=\"checked\" {{/if}} disabled=\"disabled\" style=\"display: block; margin-left: auto; margin-right: auto;\">"}
    ],
    features: [
        { name: "Filtering", mode: "advanced", type: "local" },
        { name: "Sorting", type: "local" }]
});
 

Do note that the first column also has a template – a link to the very same table’s description on MSDN – and, as it is visible, that does not stop the checkboxes from appearing in addition to working just fine with features such as sorting and filtering:

Enhancements

The above template is but a mere rendering tweak and doesn’t come with an interaction package. One other fair point made by customers is that the default interaction can be improved as Checkbox column requires 3 clicks to update – which is how row editing with selection behaves – 1 click to select, another to enter edit and third to change the value. Event though this wasn’t the original issue, since you are now in control of the checkboxes, why not improve things a bit?

The first step is to remove the disabled part, of course. Then you would need to handle user interaction with the checkbox – so add something along the lines of:

  data-rowid=\"${BusinessEntityID}\" onchange=\"checkboxChanged(event);\"
 

to the template. For enabled checkbox inputs onchange and click events are basically interchangeable, so pick one, but the name of the parameter passed to the handle *must* be ‘event’. The ‘data-‘ attribute is the easiest way to store information for the checkbox location – the grid does the same thing with rows elements if you take a closer look and it’s much easier to store it at creation as you then have access to the separate row data entry and will hardly add any overhead. Now just how easy it is with the Updating API to put that template to use:

 function checkboxChanged(evt) {
    // get rowID where change occured:
    var rowId = $(evt.currentTarget).data().rowid;
    $("#grid").igGridUpdating("updateRow", rowId, { "SalariedFlag": evt.currentTarget.checked });
}
 

Using the jQuery data() method gives us that row Id in a snap and the passed event can tell us the state of the checkbox to assign to that column value. Do note that this requires Updating to be loaded as a resource and added to the grid features(). And that leads to some issues that may arise

When Updating enters the scene..

It’s fairly reasonable to assume, since editing the checkboxes and Updating are already involved, that the grid is supposed to provide the full editing experience. However, once edit mode activated the edited cell/row UI is separate one, which means that if you don’t implement a provider yourself you will get the default combo-style editor:

Now that may or may not be a problem for you (it will work just fine and checkboxes will update once you exit edit mode), but the sake of consistent experience it would be nice if the editor could be a checkbox as well..preferably the same one. At this point you have quite a few options, really, I’ll just provide a few examples how I think this can be made better and usable.

One little trick to try is setting that very same column as read-only. You already have a control that sets the value of the cell regardless of edit state and therefore you can go ahead and set that very same column as read only! What that would do is prevent the cell from getting its UI replaced by editor and in row mode it will remain unchanged. That means no combo like above and the very same checkbox with the same event handler still there ready for action. One tweak required though – since the Update Row method is not meant to be called from within edit session it will update the UI. All good? Nope. The issue is that in the case where you have the grid with the above setup and attempt updating a row when editing is activated – then awkward behavior is guaranteed. The UI is updated, but the editing is still active even though the grid looks like it exited that one and since there are not buttons or other elements that handle the editing of the editing session.. well it’s stuck. I see a few options here, things like ending the editing (method is available of course) before calling the update row, but that immediately exits on checkbox change and that is probably not what the user would be expecting to happen. Then again you can disable the checkboxes while editing, but that’s not the way to go when editing is active.

What you can do is save the change directly to the data source transaction logs, after all the checkbox will take care of its UI, but it might require additional work (data dirty event, rebinding) to work properly with other features. You can also simply restart the editing on the very same row for the user:

 function checkboxChanged(evt) {
    // get rowID where change occured:
    var rowId = $(evt.currentTarget).data().rowid;
    // if editing is active - update just the cell, otherwise use row update
    if($("#grid").igGridUpdating("isEditing")){
        $("#grid").igGridUpdating("endEdit");
        $("#grid").igGridUpdating("setCellValue", rowId, "SalariedFlag", evt.currentTarget.checked);
         
        //optionally can start the editing on the same row again
        //need row index:
        var rows = $("#grid").igGrid("rows");
        var rowIndex;
        //var context = this;
        $.each(rows, function (index, row) {
            if ($(row).data().id == rowId) {
                rowIndex = index;
            }
        });
        //make sure you let the calling code exit before attempting start edit,
        // a few milliseconds should be enough
        setTimeout(function () { $("#grid").igGridUpdating("startEdit", rowIndex, 1); }, 2);
    }
    else {
        $("#grid").igGridUpdating("updateRow", rowId, { "SalariedFlag": evt.currentTarget.checked });
    }
}
 

Above snippet shows getting the row index from the ID and starting editing on that row with a small delay (event handler is called within anonymous function elsewhere). Ending and starting editing causes the change of UI, which in turn causes a slight flicker, but with some desire and CSS tweaking that can be changed.

Do note that you can explore the possibility of creating custom editor provider for even better experience and I will show some about that in the next part.

No Boolean? No problem!

If you noticed so far there’s a really weak connection between the actual value and the representation – our logic dictates both representation and interaction result. SO nothing is really stopping you to use more than just Boolean – strings, numbers, null values – all quite plausible. Perhaps explore more than two states of the checkbox as well. Let’s have AdventureWorks’ SpecialOffers table where a MaxQty property for each offer states a maximum OR ‘NULL’. I want to not just display that data, I want to display an result of assessment of that instead. Might not be the best example, but I will have a column that will instead show if the offer has a maximum at all:

 $.ig.loader(function () {
    $("#grid").igGrid({
        primaryKey: "SpecialOfferID",
        height: 550,
        dataSource: "@Url.Action("SpecialOffersData")",
        autoGenerateColumns: false,
        columns: [
            { key: "SpecialOfferID", width: "100px", headerText: "ID", dataType: "number" , template: "<a style=\"font-size:20px;\" href=\"http://msdn.microsoft.com/en-us/library/ms124455(v=sql.100)\">${SpecialOfferID}</a>"},
            { key: "Description", width: "250px", headerText: "Description", dataType: "string" },
            { key: "Type", width: "220px" , headerText: "Type", dataType: "string" },
            { key: "MaxQty", width: "150px", headerText: "Has MaxQty", dataType: "string", template: "<input type=\"checkbox\" {{if parseInt(${MaxQty}) }} checked=\"checked\" {{/if}} data-rowid=\"${SpecialOfferID}\"  data-test=\"${MaxQty}\" onchange=\"checkboxChanged(event);\" style=\"display: block; margin-left: auto; margin-right: auto;\">"}
        ],
        features: [
            { name: "Filtering", mode: "advanced", type: "local" },
            { name: "Sorting", type: "local" },
            { name: "Updating"}]
    });
});
 

Note the checkbox is being checked only if the value is not one of the ‘false’ equivalents (parsing returns NaN for example when it fails). Also you can set the values in much the same way – add null for false and default/calculated value for true:

 function checkboxChanged(evt) {
    // get rowID where change occured:
    var rowId = $(evt.currentTarget).data().rowid;
    var newValue = evt.currentTarget.checked ? 10 : null;
    $("#grid").igGridUpdating("updateRow", rowId, { "MaxQty": newValue });
}
 

The results (both from SQL Management Studio and the running app with the jQuery Grid):

And again the mentioned Updating tricks can be implemented for this in an identical manner.

Moving on

Here’s a quick comparison between the DIY template vs. the default Checkbox column:

PROS

Will work with other templates.
Easy to implement - 1 line for simple scenarios.
Not Limited to just Boolean values.
As a custom solution it is not limited to a bi-state checkbox, an tri-state checkbox can be potentially implemented()

CONS

Does require some code to achieve similar results.
Can be somewhat complicated to implement IF it is also required to function within the Updating edit mode. Overall in tricky relationships with the Updating feature.
The browser implementations don’t look anything special and (correct me if I’m wrong) are not guaranteed to look the same either.

Hopefully this experience was helpful for all of those that have greater functionalities in mind in that defaults can provide. As I said above this is just me sharing experience, there’s a learning curve here and this is not the only or final solution. Stay tuned for another approach in upcoming blog!

Demo project is available for download. As always, you can follow us on Twitter @DamyanPetev and @Infragistics and stay in touch on Facebook, Google+ and LinkedIn!

Creating Windows Phone Applications with Infragistics XamList

dpetev — Wed, 04 Jul 2012 13:32:00 GMT

I explained why I think list controls are THE grids for mobile phones when introducing the jQuery Mobile version. I believe most would agree they really aim to achieve pretty much the same functionality but within the limited space of a small screen and with the right kind of interaction. Then you could have a look at any of the Infragistics platform product lines… notice every product is packed with powerful grid controls? Now that the mobile platforms got some additions, if you are a Windows Phone developer with big data in mind, you need to look no further:

The XamList is here!

Just in case you missed it, of course. You can say the last release closed the loop in terms of data handling for our phone control packages and this List control is truly a feat – built for the ground up specifically for Windows Phone. I dare say it’s everything you’d expect – stylish, heavy on data and light on the app as it is virtualized. The latter doesn’t really stop it from maintaining an awesome flick experience either. But that’s not really the functionality I’d like to talk about, those are things expected of a good control and this particular one offers so much more. I’m afraid it will be too much to cover in one blog, but hey – here’s a list:

Complete control on looks – you can define templates for anything and everything.
Comes complete with a few ready-to-use templates for very quick set up.
Built-in support for hierarchy (drill-down) – That’s right! No need for details page, the XamList can do that for you. There’s more – it’s not just details page – frankly, I’m not sure the level of hierarchy supported even has a limit. And you can template every sub-view and you can drill down to different collections of items as well!
Fully featured search with the ability to control the scope of fields to be evaluated.
Filtering – again complete with the ability to define presets with just a few properties. Presets are defined in groups (sets) with special interaction to let the user activate more than one filter.
Sorting with presets for sorts based on different properties.
Grouping items with the greatest ease and support for alphabetic grouping, by property value or by date with awesome interactions designed for each type.
Custom everything – when all the defaults won’t fit you scenario, create custom sorts with your own comparer, filtering with your filter logic, group items with custom provider.

The XamList truly comes packed with features (probably even missed some) and flexibility. On a side note – while you can style nicely, I probably won’t do such a good job, so I’ll rely on the minimalistic defaults and tease you with looks from the Samples Browser (It’s on the market and it’s free!):

A Quick Setup

Model - I chose to use a very nice OData Service provided by INETA Live that offers a fairly long list of authors/speakers to fit in a list. To use it, of course, in my demo I have a reference to service, which is at http://live.ineta.org/InetaLiveService.svc/ and the following model for the Authors:

 namespace XamListApp
{
    public class MainViewModel : INotifyPropertyChanged
    {
        public MainViewModel()
        {
            this.Authors = new DataServiceCollection<LiveAuthor>();
        }
 
        INETALivePublic context;
 
        private DataServiceCollection<LiveAuthor> authors;
 
        public DataServiceCollection<LiveAuthor> Authors
        {
            get { return authors; }
            set
            {
                authors = value;
                authors.LoadCompleted += new EventHandler<LoadCompletedEventArgs>(authors_LoadCompleted);
                NotifyPropertyChanged("Authors");
            }
        }
 
        public bool IsDataLoaded { get; private set; }
 
        /// <summary>
        /// Load data.
        /// </summary>
        public void LoadData()
        {
            context = new INETALivePublic(new Uri("http://live.ineta.org/InetaLiveService.svc/"));
            Authors = new DataServiceCollection<LiveAuthor>(context);
            var query = from auths in context.LiveAuthors.Expand("LivePresentations") select auths;
            Authors.LoadAsync(query);
        }
 
        void authors_LoadCompleted(object sender, LoadCompletedEventArgs e)
        {
            if (Authors.Continuation != null)
            {
                Authors.LoadNextPartialSetAsync();
            }
            IsDataLoaded = true;
        }
 
        public event PropertyChangedEventHandler PropertyChanged;
        private void NotifyPropertyChanged(String propertyName)
        {
            PropertyChangedEventHandler handler = PropertyChanged;
            if (null != handler)
            {
                handler(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }
}
namespace XamListApp.INETAService
{
    public partial class LiveAuthor : global::System.ComponentModel.INotifyPropertyChanged
    {
        
        /// <summary>
        /// Added Image property
        /// </summary>
        [System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Services.Design", "1.0.0")]
        public string Image
        {
            get
            {
                return "/XamListApp;component/speaker.png";
            }
        }
    }
}
 

There is a second (identical in structure) model for the Live Groups feed.

As mentioned the list offers a set of standard templates you can use to jump start an app. But you can go even simpler than that – by default the XamList will display the result of the ToString() method for each record and if you data is suitable for this all you need to do is bind the ItemsSource property to it:

 <ig:XamList x:Name="xamListQuick" ItemsSource="{Binding Authors}"/>
 

Or in our case where the data object is a bit more complex and doesn’t have a proper ToString method, you can easily pick one property to show using the DisplayMemberPath:

 <ig:XamList x:Name="xamListQuick" ItemsSource="{Binding Authors}"
            DisplayMemberPath="FirstName"/>
 

Quick Templates

Then again so far we got a single name and that doesn’t really tell much. The default templates offer more – a Title Only (the one we have so far), with added Thumbnail and with both thumbnail and description. Notice in the model above I’ve added an additional Image property to the Authors (line 58 and on) so I can demonstrate this:

 <ig:XamList x:Name="xamListQuick" 
            ItemsSource="{Binding Authors}"
            ItemLayout="ThumbnailTitleAndDescription">
    <ig:XamList.ItemLayoutBindings>
        <ig:ItemLayoutBinding ItemLayoutProperty="ThumbnailSource" Path="Image"/>
        <ig:ItemLayoutBinding ItemLayoutProperty="Title" Path="FirstName"/>
        <ig:ItemLayoutBinding ItemLayoutProperty="Description" Path="LastName"/>
    </ig:XamList.ItemLayoutBindings>
</ig:XamList>
 

And then you can simply activate some of the features like Group speakers by first letter (alphabetic) and allow for them to be sorted with a few extra lines (these go inside the list definition from above):

 <ig:XamList.Grouping>
    <ig:AlphabeticGrouping GroupByMemberPath="FirstName" />
</ig:XamList.Grouping>
<ig:XamList.SortPresets>
    <ig:SortPreset DisplayText="First Name" Field="FirstName"/>
</ig:XamList.SortPresets>
 

And the end result is both good looking and functional:

Another way

If those defaults don’t quite fit your tastes you can easily do a super quick template – in my case with authors the image really wasn’t available and not necessary. Then again I have first and last name and I would like to have them in a single row as the title and the Bio as description text:

 <ig:XamList.ItemsTemplate>
    <DataTemplate>
        <StackPanel>
            <StackPanel Orientation="Horizontal">
                <TextBlock Text="{Binding FirstName}"/>
                <TextBlock Text="{Binding LastName}" Margin="8,0,0,0"/>
            </StackPanel>
            <TextBlock Text="{Binding Bio}"/>
        </StackPanel>
    </DataTemplate>
</ig:XamList.ItemsTemplate>
 

Some styling required, but this is the general way you can build the List UI just the way you like it.

A slight issue

Now that you have an app running you may want to try the built-in search (taping the icon expands a textbox to enter criteria) and get this by accident:

And I don’t mean the result (Oh look! It’s our very own Jason Beres!). Take a look at the search criteria – 44?! The things is the search by default will attempt to really find everything you need by searching every property of the list items and as it turns out each LiveAuthor has an ID and Jason’s for example is 44. Assuming you end up in the situation with more properties than it is reasonable to display in the list, you might want to restrict the set of properties to be searched by adding the following to the other settings above:

 <ig:XamList.ScopePresets>
    <ig:ScopePreset DisplayText="First Name" Field="FirstName"/>
    <ig:ScopePreset DisplayText="Last Name" Field="LastName"/>
</ig:XamList.ScopePresets>
 

Hierarchy

I find the automatic drill-down feature to be one of the most outstanding features of this control. And it’s not so hard too. And as I said – there are templates for a almost everything. Above were showed the built-in ones and the general Items template. Now those wouldn’t be very appropriate to use when you have hierarchy for the sole reason you’d want to display different items when drilling down. If you haven’t already guessed, yes – there are more templates you can set instead. Actually it’s more of a Type Defined

templating that anything else. The trick about this type of template definitions is that you can use them for other purposes as well (like defining different layouts for different types of items in your data source – see the sample with books and movies screenshot above). The List has a Global ItemLayouts collection where you can define yours and set a target type for each. In the code below you can see templates for the ‘LiveAuthor’(line 2) and ‘LivePresentation’ (line 53) and they are actually part of one list and keep in mind the presentations are collection too:

 <ig:XamList.GlobalListItemLayouts>
                    
    <ig:ListItemLayout TargetTypeName="LiveAuthor">
        <ig:ListItemLayout.ListItemTemplate>
            <ig:ListItemTemplate>
                <ig:ListItemTemplate.PortraitItemTemplate>
                    <DataTemplate>
                        <StackPanel Orientation="Horizontal">
                            <TextBlock Text="{Binding PresentationCount, Converter={StaticResource countConverter}}" FontSize="22" FontWeight="Bold"></TextBlock>
                            <TextBlock Text="{Binding FirstName}"></TextBlock>
                            <TextBlock Text="{Binding LastName}" Margin="8,0,0,0"></TextBlock>
                        </StackPanel>
                    </DataTemplate>
                </ig:ListItemTemplate.PortraitItemTemplate>
            </ig:ListItemTemplate>
        </ig:ListItemLayout.ListItemTemplate>
                        
        <ig:ListItemLayout.DetailItemTemplate>
            <ig:DetailItemTemplate>
                <ig:DetailItemTemplate.DrillDownSettings>
                    <ig:DrillDownSettings DrillDownTargetPath="LivePresentations" AutomaticDrillDown="False"/>
                </ig:DetailItemTemplate.DrillDownSettings>
                <ig:DetailItemTemplate.PortraitItemTemplate>
                    <DataTemplate>
                        <ScrollViewer Height="Auto">
                            <StackPanel>
                                <Image Height="48" Width="48" Margin="5" HorizontalAlignment="Left" Source="appbar.back.rest.png">
                                    <igBase:Commanding.Command>
                                        <ig:XamListCommandSource CommandType="GoBack" EventName="Tap" TargetName="xamList"/>
                                    </igBase:Commanding.Command>
                                </Image>
                                <StackPanel Orientation="Horizontal" Margin="0,0,0,5">
                                    <TextBlock Text="{Binding FirstName}" FontFamily="Segoe WP Semibold"></TextBlock>
                                    <TextBlock Text="{Binding LastName}" Margin="8,0,0,0" FontFamily="Segoe WP Semibold"></TextBlock>
                                </StackPanel>
                                <TextBlock Text="{Binding Bio}" TextWrapping="Wrap" TextTrimming="WordEllipsis" MaxHeight="350"></TextBlock>
                                <StackPanel Height="48" Orientation="Horizontal">
                                    <igBase:Commanding.Command>
                                            <ig:ListItemControlCommandSource CommandType="DrillDown" EventName="Tap"/>
                                        </igBase:Commanding.Command>
                                      <TextBlock VerticalAlignment="Center"> Presentations </TextBlock>
                                    <Image Height="48" Width="48" Source="appbar.next.rest.png"/>
                                </StackPanel>
                                    <TextBlock Text="{Binding URL}" TextWrapping="Wrap"></TextBlock>
                            </StackPanel>
                        </ScrollViewer>
                    </DataTemplate>
                </ig:DetailItemTemplate.PortraitItemTemplate>
            </ig:DetailItemTemplate>
        </ig:ListItemLayout.DetailItemTemplate>
    </ig:ListItemLayout>
                    
    <ig:ListItemLayout TargetTypeName="LivePresentation" AutomaticDrillDown="False">
        <ig:ListItemLayout.ListItemTemplate>
            <ig:ListItemTemplate>
                <ig:ListItemTemplate.PortraitItemTemplate>
                    <DataTemplate>
                        <StackPanel Margin="0,0,0,20">
                            <TextBlock Text="{Binding Title}"></TextBlock>
                            <Line Margin="1"></Line>
                            <TextBlock Text="{Binding Abstract}" TextTrimming="WordEllipsis" Height="60"  TextWrapping="Wrap" Style="{StaticResource PhoneTextNormalStyle}"></TextBlock>
                        </StackPanel>
                    </DataTemplate>
                </ig:ListItemTemplate.PortraitItemTemplate>
            </ig:ListItemTemplate>
        </ig:ListItemLayout.ListItemTemplate>
    </ig:ListItemLayout>
</ig:XamList.GlobalListItemLayouts>
 

Each ListItemLayout in the Global collection has both list (item) and details templates and notice they each have Portrait template defined…that’s because you can specify a different one for the Landscape orientation! Also they have Automatic drill down property (default is true, so you can skip it).

The absolute best part is that I have defined two types of collections and yet only one list and I can drill down to the Presentations collection from within each author item thanks to the Drill down Path property. And here’s a small hierarchy flow of what this will do:

Commands

Guess I missed that one in the listing at the start – simply put the List comes with two default command sources – the List itself which you can see in the above code (lines 27-31) where it is used to create a back button from an Image. This source also provides a set of the most common functionalities for you to use, such as applying a filter, toggling filter and search states and jumping to groups.

And then you have the List Item which provides a single, yet critical command – drill down! This is useful if you don’t want or can’t use the automatic drill-down feature and you can use this to add a button that does that inside the list item itself. You can see that in action in the Samples Browser (It’s the “Non Automatic Drilldown”).

Custom Grouping

So far I’ve showed you an alphabetic grouping in the first example and now if you look at the second it is also grouped. But those are user group names that are not included in the ‘LiveAuthor‘ or their ‘LivePresentations’? This is where all the customization really shines, as I have defined my very own Grouping Provider that makes the connection between Author ID and Groups. However, since authors may have presented in more than one, they will be grouped in the one they have the most or the first if all are equal:

 public class GroupingProvider : IGroupingProvider
{
    public System.Collections.Generic.List<string> GetAllGroupNames()
    {
        var titles = (from grp in App.GroupModel.Groups
                      select grp.Name).ToList();
        return titles;
    }
 
    public string GetGroupNameForItem(object item)
    {
        var Id = App.ViewModel.Authors.Where(a => a.AuthorID == (int)item).FirstOrDefault().LivePresentations
            .GroupBy(p => p.GroupID)
            .Select(p => new { ID = p.Key, num = p.Count() })
            .OrderByDescending(p => p.num)
            .First().ID;
        var name = App.GroupModel.Groups.Where(x => x.GroupID == Id).FirstOrDefault().Name;
        return name;
    }
}
 

Note that the GetAllGroupNames method gets called when the user interacts with the group headers which opens up the Group picker (or jumper if you will) menu which is an overlay with all the groups returned by the method and the user can quickly jump to:

The grayed-out names are the ones that don’t have items and can’t be navigated to. Here’s a small trick however – if you return ‘null’ in the above method, this menu will only show the names that are actually available.

Code

Here’s the rest of that list complete with group settings and filter:

 <ig:XamList x:Name="xamList" ItemsSource="{Binding Authors}" ItemClicked="xamList_ItemClicked" GotFocus="xamList_GotFocus">
     <ig:XamList.ScopePresets>
         <ig:ScopePreset DisplayText="First Name" Field="FirstName"/>
         <ig:ScopePreset DisplayText="Last Name" Field="LastName"/>
     </ig:XamList.ScopePresets>
     <ig:XamList.Grouping>
         <ig:CustomGrouping GroupingProvider="{StaticResource groupingProvider}" />
     </ig:XamList.Grouping>
     <ig:XamList.FilterSets>
         <ig:FilterSet Title="Size"
                       DefaultFilterName="All">
             <ig:FilterPreset Name="All"  DisplayText="All"/>
             <ig:FilterPreset Name="A"
                              DisplayText="Starst with A"
                              Field="FirstName"
                              Operator="StartsWith"
                              Value="A" />
         </ig:FilterSet>
     </ig:XamList.FilterSets>
     <!--The global list templates here-->
 </ig:XamList>
 

Bonus screenshot

I mentioned grouping has special interactions for the different types (the custom above is like a value type). Then you have the alphabetic from the first example and taping its headers brings up a very familiar styled menu:

Wrapping Up

You can tell I was very serious when I said the XamList has quite the feature set – I pretty much skipped some features like filtering (although you can see one filter definition in the Code section above), but remember you can customize that and sorting too? Don’t forget you get search with scope tweaking, amazing grouping with defaults for letters and dates and the best feature ever – the automatic drilldown that can build entire applications with a single list!

This control combines a few awesome sides – it can be as simple as it gets with built-in templates and spot-on defaults for all features and then it all can be templated to your liking and customized to your needs. It’s truly a grid-type control that is ready to handle large data and various scenarios.

Download the demo project for this blog( two list samples with all of the above described), keep in mind you’ll need Windows Phone SDK and at least trial (it’s free) version of NetAdvantage for Windows Phone. As always, you can follow us on Twitter @DamyanPetev and @Infragistics and stay in touch on Facebook, Google+ and LinkedIn!

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!

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!).

New High Performance jQuery Templating Engine

dpetev — Mon, 09 Apr 2012 06:33:00 GMT

As an avid reader of our blogs (we are sure you are), you might have noticed some topics regarding templating our controls or parts of them. As part of that came a minor catch – templating required (and as long as we are waiting for 12.1, it still does) the jQuery Templates Plugin and as a part of roadmap change it was decided that it will not be developed past its current beta status and an entirely new one is in planning. We strive to provide a well-rounded package of functionality with our jQuery product, so you wouldn’t usually need to look for additional solutions to support out controls. Along with that, we make sure to pack plenty of all the advantages new technologies provide so you get a product that goes..fast! I pointed those two ideology pillars of the product, because both of them led to the creation of our very own Template Engine – we made sure our users can use such features, while being certain we would provide support and most importantly we will strive to make the most out of it – we offer controls supporting very large amounts of data and now we offer the engine to template them swiftly.

Introduction

Let’s provide some basics for those unfamiliar with templating. Such technique provides a way to define a one layout(to be applied to many records) and indicate how and where each piece of your data should be via a special syntax that would be recognized by the template-providing scripts. You can then relax while the latter take your data, find it’s place, replace it and build your layout. It is in essence creating a tailored-to-your-data layout on the client side – that can reduce the load on your server! Now you have that much greater control over where should UI generation put its weight. Also it needs to support the current functionality covered by jQuery Templates and for that reason differences in terms of how it functions are kept to the bare minimum as far as the developer using the controls is concerned – if you are already using templating for our grid we would not ask you to learn something completely new or you might not even need to change you code.

And that is, of course, not not the full story yet – while it was needed for some controls, the template engine was designed to be fully functional stand-alone feature. Which means that you can use the engine to template any data anywhere into anything really. All you really need is jQuery defined and to load igTemplating which can be done like so:

<script type="text/javascript">
    $.ig.loader({
        scriptPath: "../../Scripts/Infragistics/js/",
        cssPath: "../../Content/Infragistics/css/",
        resources: "igTemplating"
    });
</script>

At this point you have a tmpl method available in the infragistics namespace – $.ig that you can call to ‘render’ you template.

The engine is fully integrated in out tree, combo and grid controls, which means you don’t even have to reference it(as seen above) – it’s enough to load one of the above and templating will be made available as well.

So to make it short – you get a high-performance templating engine capable of working stand-alone as well as integrated with our controls and in a format you might be already familiar with or at least is easy to learn.

In a snap!

So we are to talk performance – if and until we do publish results from some official testing, you might have to trust my word for it, but as we said before it was designed with that main goal in mind. That led to separating the template producing logic into two branches – one that would handle the simple property –>actual data substitution and it is lightning fast. The second would handle more complex operations including, such as conditions and loops (will explain those below) and those operations require creating a JavaScript function to apply those ‘rules’ and it must be executed on every pass. That means it would be somewhat slower. One Other thing that can affect performance is encoding and you are, of course, given a way to control it.

Furthermore, the engine outputs a sting rather than objects (which makes for great performance) and some preliminary testing attempts showed mind-boggling speeds when you use it for simple substitution without encoding and even if encoding is required it will outperform one of available alternatives (that itself is much faster the the jQuery Templates)!

What can you do with it?

The engine will recognize a certain grammar, if you will. Along with all your data properties (tokens) in the template, the engine has denied regular expressions to help it identify comments(enclosed with ‘#’) and substitutions(data tokens) in the following formats:

${prop} – encoded
{{html prop}} – with encoding

The difference with encoding , besides performance, is that if your data contains HTML itself the output will be different. Let’s say you have data like:

{ Name: "<img/>ASP.NET", Color: "olivedrab2", Color2: "#B3EE3A/#9ACD32" },
{ Name: "<a href=\"#\">Windows Forms<a>", ...

And depending on whether you use {{html Name}} or ${Name} in you template you will get accordingly:

or when encoded:

A very basic substitution

Assume you have a HTML ul element with id ‘productListing’ and the following data and script:

//------ Basic:------
var products = [
{Name: "Chai", InStock: "33", OnOrder: "2" },
{ Name: "Chang", InStock: "17", OnOrder: "40" },
{ Name: "Aniseed Syrup", InStock: "13", OnOrder: "70" },
{ Name: "Chef Anton's Cajun Seasoning", InStock: "53", OnOrder: "0" },
{ Name: "Chef Anton's Gumbo Mix", InStock: "0", OnOrder: "0" },
{ Name: "Grandma's Boysenberry Spread", InStock: "120", OnOrder: "0" },
{ Name: "Northwoods Cranberry Sauce", InStock: "6", OnOrder: "20" },
{ Name: "Mishi Kobe Niku", InStock: "52", OnOrder: "20" },
{ Name: "Uncle Bob's Organic Dried Pears", InStock: "15", OnOrder: "33" }
];
/* THE template */
var theTemplate = "<li><b>${Name}</b> ({{html InStock}}) [Ordered: {{html OnOrder}}]</li>";
/* Render the template */
var result = $.ig.tmpl(theTemplate, products);
/* Add the ready markup to the div: */
$(result).appendTo("#productListing");

The result from this would be something like this (depending on page default styles):

As you can see you can build html markup, mark places for data and it will be generated for each of your records. Now things get a bit more interesting if you have some hierarchical data:

//------ With nested:------
var productsWithHierarchy = [
{ Name: "Chai", InStock: "33", OnOrder: "2", Test: { Inner1: "inner text 1.1", Inner2: "inner text 1.2"} },
{ Name: "Chang", InStock: "17", OnOrder: "40", Test: { Inner1: "inner text 2.1", Inner2: "inner text 2.2"} },
 { Name: "Aniseed Syrup", InStock: "13", OnOrder: "70", Test: { Inner1: "inner text 3.1", Inner2: "inner text 3.2"} },
];
/* THE template */
var theTemplate2 = "<li><b>${Name}</b> ({{html InStock}}) [Ordered: {{html OnOrder}}] <ul><li> {{html Test.Inner1}}</li> <li>{{html Test.Inner2}}</li></ul> </li>";
/* Render the template */
var result2 = $.ig.tmpl(theTemplate2, productsWithHierarchy);
/* Add the ready markup to the div: */
$(result2).appendTo("#hierListing");

Notice the ‘Test.Inner1’ - navigating nested properties is very easy to do and the result from this is:

What if…

So, what happens when you don’t want to apply the template blindly to all records? - You build a conditional block to handle that. The engine recognizes a number of directives such as logical blocks:

{{ if }} conditionals
{{else}} conditionals
{{elseif}} conditionals
{{each}} loop

And a reserved $i identifier for the current index in a loop. All that can make up for some pretty interesting capabilities.

You can go very deep with this as you can nest multiple else-if conditions inside the ‘if’ and the ‘else’ will be your default. All blocks must be closed to be recognized and their closing tag is the same with added slash. However, there is something very important to note – due to the way blocks are recognized, it is not possible to have two consecutive ‘if’ blocks, as in:

{{if condition}} /* work 1 */ {{/if}} {{if condition2 }} /* work 2 */ {{/if}} – as the very last closing will be assigned to the very first and therefore will not allow for such logic. At this point though let’s have a relatively simple example – same as the first simple substitution lets have our products, this time however lets check if we have enough items in stock to cover our orders and provide some sort of visual for insufficient ones – yes we can do all that in the template like so:

//------ Conditional:------
 var theTemplate3 = "#This time we will be using table as output#" + 
 "<tr> <td><b>${Name}</b></td>" +
 "# Here is the IF block #" +
 "{{if (${InStock} - ${OnOrder}) < 0}} <td style=\'color:red;\'>(${InStock})</td>' + 
 "# And the Else (default) block with the same template but without the style #" + 
 "{{else}}<td>(${InStock})</td> {{/if}}<td>[Ordered: ${OnOrder}]</td> </tr>";

Resulting in:

So we made a very simple warning system for our user. You can apply the same type of logic to check the record index (using the reserved ‘$i’) to apply special templates to select rows and naturally create alternative row layouts and so on.

Of course, you are not limited to just local arrays – the Templating engine can take data from functions and it can pass parameters if required. Along with that, you have all the freedom to produce markup of any kind and that includes placing data inside HTML elements classes, id-s.. you name it! Here’s an example, where a few styles applied to class names and the said class names are available in our data:

//------Data function------
function productFamily(count) {
    var NetAdvantage = [
    { Name: "ASP.NET", Color: "olivedrab2", Color2: "#B3EE3A/#9ACD32" },
    { Name: "Windows Forms", Color: "turquoise2", Color2: "#00E5EE" },
    { Name: "WPF", Color: "slateblue4", Color2: "#473C8B" },
    { Name: "Silverlight", Color: "magenta4", Color2: "#8B008B" },
    { Name: "jQuery", Color: "mediumaquamarine", Color2: "#66CDAA" },
    { Name: "SharePoint", Color: "gold", Color2: "gold" },
    { Name: "iOS", Color: "gray", Color2: "gray" },
    { Name: "Silverlight Data Visualization", Color: "orange", Color2: "orange" },
    { Name: "WPF Data Visualization", Color: "yellow", Color2: "yellow" },
    { Name: "Windows Phone", Color: "dodgerblue", Color2: "#1E90FF" },
    { Name: "Visual Studio LightSwitch", Color: "darkslateblue", Color2: "#483D8B" },
    { Name: "TestAdvantage", Color: "red", Color2: "red" },
    { Name: "Icons", Color: "green", Color2: "green" }            
    ];
    var result = [];
    if (count > NetAdvantage.count()) { count = NetAdvantage.count(); }
    for (i = 0; i < count; i++) {
        result.push(NetAdvantage[i]);
    }
    return result;
}
var theTemplate4 = "<div class=\"${Color}\">{{html Name}}</div>";
/* Render the template */
var result4 = $.ig.tmpl(theTemplate4, productFamily, [7]);

This template will simply cause DIV-s for each product to be generated with class that contains their color (by which the CSS will be applied). Also calling the data function we provided parameter - the number of products to display. The result looks like:

Beyond

The igTemplating Engine truly gives you a lot of freedom - in terms of how to place your content, whether you would use it on it’s own or you can do some eye-catching wizardry with the tree, combo or grid and enhance them with functionality and style at the same time. Since you can easily build markup, you can take data that was not readily available and essentially format in a way that a UI control can transform – yes, that means templating table to turn then in an igGrid form example, or a table in another table and.. well you get the point. You can assign classes and Ids and you can target those to turn them into completely different UI. You can also enjoy the functionality that was so far available to template our jQuery tree and grid controls and soon you will also have a column template for the grids, in addition to the current row option.

The good news around customizing your data presentation are far from over and this new Templating Engine is ready to take care of it and most importantly do it extremely fast!

Expect a demo for this blog once 12.1 is made available, samples and more ways you can make the best out of such functionality. Meanwhile you can check out blogs that demonstrate templating (with jQuery Templates, though they should still give you an idea of the capabilities):

jQuery Templating Tips & Tricks (demonstrated with the grid)
Setting up Node Template in the jQuery igTree
Multi-column jQuery combo box with templates

And as usual you can check out the samples for each of those controls for more.

Search results matching tag 'Templating'

jQuery Grids and Responsive Web Design

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

Customizable, we need it to be customizable!

Power to the user

Resources

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

IgniteUI jQuery Grid Unbound Columns: Updating and Hierarchy

To Save or not to Save

Custom Deserialization

“My Unbound values don’t reach the server”

Formula Trouble

Hierarchical Grid with Unbound Columns

Setting values and child column layouts

Load On Demand and Merge Unbound columns don’t go well…

GetData() to the rescue

Bonus scene (formula + template)

Resources and demos

TL;DR | Summary

jQuery Grid Unbound Column: How to make the most of it

Merge Unbound Columns

Merged Unbound columns distinctive property – unboundDS

Performance

Client-side data manipulation

Merging Unbound Columns and setting values on data-bound client event

Get them!

It’s Complicated

Resources and demos

TL;DR | Summary

jQuery Grid Checkbox Column alternatives (continue)

The Checkbox column feature to the rescue!

The template

One-click inline value updates

Editing Action

Editor provider

Comparison

PROS

CONS

Conclusions

jQuery Grid Checkbox Column alternatives

The problem

A solution

Template Checkbox

Enhancements

When Updating enters the scene..

No Boolean? No problem!

Moving on

PROS

CONS

Creating Windows Phone Applications with Infragistics XamList

The XamList is here!

A Quick Setup

Hierarchy

Commands

Custom Grouping

Code

Wrapping Up

jQuery Mobile Controls by Infragistics

Enter the Infragistics jQuery Mobile controls

A Mobile App

Wrapping Up

Column Templates for the jQuery Grids

Just a few steps

Conclusion

New High Performance jQuery Templating Engine

Introduction

What can you do with it?

Beyond

<script>

function customValidation(element) {

// omitted

}

</script>