Damyan Petev's Blog

Responsive Web Design with jQuery Grids: A closer look

[Infragistics] Damyan Petev — Thu, 23 May 2013 21:11:00 GMT

I really hope I got you excited about the Responsive Web Design mode for the Ignite UI Grids last time – as it is the kind of an unique feature that truly makes this jQuery control stand out! As previously explained it’s not exactly a simple thing to make a grid responsive, but our team made serious considerations on how to best approach this and I do believe they’ve pretty much nailed it and this will turn out to be very useful addition. There were also plenty of things that can’t fit in a single blog, plus the fact that the actual feature was not yet released so there wasn’t too much of demo material to see. So now, with 13.1 out and even accompanied by a service release, without further due, let’s dig into the technical stuff! I’ll start with some interesting design considerations and even potential pitfalls related with Responsive Web Design and then have some specific Grid tips.

A Getting Started, of sorts

Now these are more of honorary mentions as the most basic stuff were already covered elsewhere, but hey, it doesn’t hurt to have them on a speed dial. So in case you missed it - here’s a nice summary on Building responsive web design using CSS3 Media Queries!

And because creating a Responsive app is all in the name of providing users with a better experience I figured some UX tips and food for thought are in order. Our Services or as of recently D3 (from Discover – Design – Develop) have a solid expertise in the field and they share some of it in their blogs. For example this on UX of Responsive Web Design you should definitely check out! There’s a whole lot more on UX, Design and usability and I highly recommend keeping an eye on those.

Once you have technology and design considerations in check, I’d like to turn your attention to the now available Documentation for the igGrid Responsive Web Design (RWD) Mode. There’s an good coverage on the theory behind this and also a good amount of examples! Speaking of which, you can also check out our samples for Responsive Web Design Custom Mode Template Switching and Responsive Web Design Mode of the Grid with Twitter Bootstrap

Additional considerations

Some “good to know about” extras – like the browser viewport. One of the most important things to consider is that many (if not all) smartphone browsers will 'lie' about their dimensions. It's not a bad thing, mind you – most phones these days have such high dpi that it will be impossible to read and interact normally with pages where everything is shrunk to the native resolution. Instead, as you can read on CSS pixel ratios (or, why all mobile sites are 320 pixels), pixels we would use for web development are now relative. The term ‘CSS pixels’ also pops up here and there, but basically the browser will almost always scale the pixels down (so 1 pixel will actually be multiple physical ones), which in term affects the browser viewport dimensions. Those dimensions, usually wider than the screen, are still small enough to squish a non-responsive page and big enough to force the user to scroll. This is where the all-time favorite meta tag comes in setting the viewport to match the device width (which removes that annoying scrolling) but limits your space further, something in the range of 320 – 460 of them virtual pixels! Remember the utility class table from Bootstrap I showed last time? I hope it does it make sense now why phones end up in their respective visibility class even in landscape.

On the other side are tablets where many have a pixel ratio of 1 or 2 in the case of retina displays, but for all intents and purposes tablets usually hit the desktop size mark in landscape and only get to the tablet-specific styles in portrait. There’s a very large and very incomplete List of displays by pixel density on Wikipedia if you wan to have a look.

There’s also an interesting issue with setting the IE10 viewport in CSS (as is per recommendation) rather than using the meta tag. The issue came out of nowhere and this blog on Responsive Design in IE10 on Windows Phone 8 helped me a lot. As it turns out, the bug applies actual physical pixels when using “device-width” in CSS. Eventually I tracked down the issue to Bootstrap’s own CSS - they applied to fix Win 8 apps in snapped mode, but it completely broke Bootstrap pages on Windows Phone. Keep that in mind, there’s a fix provided that feels hacky at best, but it does work so consider it if working with Bootstrap.

Additionally, good things to remember is that touch devices have their special needs and oddities – make sure touch targets are big enough, remember touch events are separate and in the case of the Grid – consider applying the touch-friendly Windows UI Theme. And once more, have a look around those D3 blogs for mobile and usability related articles that can help you.

Merging and Column Hiding

As I hope it has become clear the Responsive feature allows for both hiding columns through setting and modifying the structure (markup) via templates. The template swapping is a source of quite a few possible modifications, perhaps one of the most useful ones is merging columns, as you may read in the docs. Now I know this might not be necessary, but better safe than sorry: don’t attempt to hide columns through the template or merge them (e.g. writing one less <td> cell). A main thing about the Ignite UI Grid is that is has columns array you usually define or have auto-generated – either way, row templates are designed to do just that – allow you to format the already existing layout! In other words, templated columns MUST match the layout defined or all data properties if generated! You will not get any results if column definitions and markup clash. So, for hiding columns you are stuck with defining column settings (not too pretty if they are a lot, I know).

So how then exactly do you merge columns? Well one option is hiding a column though settings and adding its data to another still visible ones in a template. This is the approach you can see in our samples and it works best when the target column header is something that makes sense after you merge, like in that sample the Address taking in the country and city values as well.

Another possible way that I personally like is though an Unbound Column. That way you can have the unbound setup with multiple data properties and only revealed when other are not. For example take this part of a grid definition where you have first and last name separate and an unbound column to take their place when on phone:

 $("#grid").igGrid({
    columns : [{
        unbound : true,
        key : 'name',
        dataType : 'string',
        headerText : 'Full Name'
    }, {
        key : 'FirstName',
        dataType : 'string',
        headerText : 'First name'
    }, {
        key : 'LastName',
        dataType : 'string',
        headerText : 'Last Name'
    }],
    //...
    features : [{
        name : 'Responsive',
        forceResponsiveGridWidth : false,
        columnSettings : [{
            columnKey : 'name',
            classes: "ui-visible-phone",
            configuration: {
                phone: {
                    template: "<span>${LastName}, ${FirstName}</span>"
                }
            }
        },{
            columnKey : 'FirstName',
            classes: "ui-hidden-phone"
        },{
            columnKey : 'LastName',
            classes: "ui-hidden-phone"
        }]
    }]
    //....
});
 

Same thing using the ASP.NET MVC helpers:

 @(Html.Infragistics().Grid(Model)
    .Columns(column =>
    {
        column.Unbound("name").DataType("string").HeaderText("Full Name").Template("${FirstName} ${LastName}");
        column.For(x => x.FirstName).HeaderText("First name").DataType("string");
        column.For(x => x.LastName).HeaderText("Last Name").DataType("string");
        //...
    })
    .Features(feature =>
    {
        feature.Responsive().ForceResponsiveGridWidth(false).ColumnSettings(setting =>{
            setting.ColumnSetting().ColumnKey("name").Classes("ui-visible-phone").Configuration(conf => conf.AddColumnModeConfiguration("phone", c => c.Template("<span>${LastName}, ${FirstName}</span>")));
            setting.ColumnSetting().ColumnKey("FirstName").Classes("ui-hidden-phone");
            setting.ColumnSetting().ColumnKey("LastName").Classes("ui-hidden-phone");
            //...
        });
    }).DataBind().Render()
)
 

Essentially turning merging the two columns going from tablet to phone mode in the images below:

As you may remember and notice above, when Responsive is used with Column Hiding you get that hidden indicator that is both a cue for the user something else is there and an interaction target to modify the visible columns. In terms of usability for touch though, it does feel slightly hard to hit. Good thing you can pick its width I guess – it seems that something in the range of 14-15px is much easier to hit, which is about double the default size.

Of course, unless you arrange your columns in a way that all the ones you will be hiding are in front or at the end, you will get multiple indicators like I have above. Increasing their size for touch takes up even more of the already precious space.

So either ensure arrangement or hide the indicator entirely - well, not really since right now there is no such option, but you can always set the width to 0! How would the user know of hidden columns and interact with the feature then, you may ask? Well, the Column Hiding and its API provide you with the necessary tools to build your own user experience by adding an external button to open the column chooser dialog and events to let you know and potentially display when columns are hidden to the user. The column chooser is easy to open with a single call and hiding and showing events are fired for each column separately (by both Hiding and Responsive!) so you can keep track of their count:

<button id="openChooser"> Show/Hide Columns </button>
 <label id="hiddenColumns" data-count="0"> </label>

 $.ig.loader("igGrid.Responsive.Hiding", function () {
    $("#grid").igGrid({
        //...
        features : [{
            name : 'Responsive',
            responsiveColumnHidden: hidden,
            responsiveColumnShown: shown
        },{
            name : 'Hiding',
            hiddenColumnIndicatorHeaderWidth: 0,
            columnChooserWidth: 300,
            columnHidden: hidden,
            columnShown: shown
        }]
        //...
    });
 
    //initial state after load
    updateHiddenLabel($("#grid").data('igGrid'));
 
    $("#openChooser").igButton().click(function myfunction() {
        $('#grid').igGridHiding('showColumnChooser');
    });
});
 
function hidden(evt, ui){
    var label = $("#hiddenColumns");
    var newHiddenCount = parseInt(label.data('count')) + 1;
    label.data('count', newHiddenCount).text("(" + newHiddenCount + " hidden)");
}
function shown(evt, ui){
    var label = $("#hiddenColumns");
    var newHiddenCount = parseInt(label.data('count')) - 1;
    label.data('count', newHiddenCount).text("(" + newHiddenCount + " hidden)");
    if(newHiddenCount <= 0){
        label.data('count', 0).text("");
    }
}
function updateHiddenLabel(grid){
    var hiddenCount = 0;
    var columns = grid.options.columns;
    for(index in columns){
        hiddenCount += columns[index].hidden ? 1 : 0;
    }
    $("#hiddenColumns").data('count', hiddenCount).text( hiddenCount ? "(" + hiddenCount + " hidden)": "");
}
 

Note that you should pick a fitting size for the chooser (300 looks ideal, remember that’s in CSS pixels) as the Draggable and Resizable widgets on the chooser are not likely to work too well, unless you use one of those widgets that add touch support to jQuery UI.

Of course, you can have the indicators and extra chooser shortcut as well – all depending on what fits your design needs better.

Multi-Column Headers

When you are using jQuery Grids with this feature there’s a slight consideration to keep in mind. With Column Hiding you can hide columns in groups directly through their multi-header keys. Event though the Column Hiding feature itself allows for such API calls and we’ve also been using “hiding a column” through the Responsive feature, it’s not the same thing. Responsive, much like Hiding, is hooked to the underlying grid framework that just won’t accept such calls because they don’t exist there. So short version – Responsive can’t hide multi-columns at once through their common header, you will have to provide settings for each separately.

Responsive Hierarchical Grid

Noticing the title? ‘Grids’? Yes, plural. Decided I should show some love for those with more complicated(hierarchical) data on their hands. Sometimes by looking at what we write and demonstrate someone would think we are forgetting about the Hierarchical Grid. We aren't really, we are merely forgetting how easy it is for readers and users to forget that it is build on top of actual flat grids. You know, there's actually a very normal igGrid widget running alongside the igHierarchicalGrid every time, even for the parent layout. When we talk features and functionality, we almost always have both controls in mind and only mention special cases. Point is this particular Hierarchical Grid is not afraid of some Responsive Web Design!

The Responsive feature can be inherited but that, as with other features with column settings, won’t do you any good. In other words, the feature and its settings must be defined for each layout you want it on. Which is not half bad because you can apply separate recognizers and mode profiles for them.

Twitter Bootstrap is also supported, which is to say you can use Bootstrap CSS classes for column visibility and mode recognition. And it’s also super easy to set up. Introducing the Responsive Web Design page with Ignite UI jQuery Hierarchical Grid and Twitter Bootstrap… whoa, that’s a mouthful!

 $('#grid').igHierarchicalGrid({
    dataSource: '/Home/Departments',
    autoGenerateColumns: false,
    autoGenerateLayouts: false,
    responseDataKey: null,
    columns: [
        //...
    ],
    columnLayouts: [{               
        columns: [
            //...
        ],
        features: [{
            name: 'Responsive',
            responsiveModes: {
                phone: "bootstrap",
                tablet: "bootstrap",
                desktop: "bootstrap"
            },
            columnSettings: [{
                columnKey: 'BusinessEntityID',
                classes: "visible-desktop"
            }
            //...
            ],
            rowTemplate: {
                desktop: "<tr><td>{{html BusinessEntityID}}</td><td>{{html LoginID}}</td><td>{{html NationalIDNumber}}</td><td>{{html Gender}}</td><td>{{html BirthDate}}</td><td>{{html MaritalStatus}}</td><td>{{html JobTitle}}</td><td>{{html OrganizationLevel}}</td><td>{{html HireDate}}</td><td>{{html SalariedFlag}}</td><td><div class='progressbar'>{{html VacationHours}}</div></td></tr>"
            }
        }]
    }],
    features: [{
        name: 'Responsive',
        responsiveModes: {
            phone: "bootstrap",
            tablet: "bootstrap",
            desktop: "bootstrap"
        }
    }]
});
 

The only difference is that you have to specify the Bootstrap recognizer if you need it, and use unprefixed classes for the column visibility like “hidden-phone” and you should be good to go:

And the template you notice above is just for desktop where you can enjoy power and space so why not have a column with Gauges or sliders or progress bars in my case:

Thinking about it, you get responsive design mode grid with responsive design grids in it in a responsive web design site/app – this should totally qualify for an Inception meme!

Resources

I have some interesting tips and tricks coming up next, so stay tuned!

The super hacky JSFiddle on Responsive Web Design page with Ignite UI jQuery Hierarchical Grid and Twitter Bootstrap. That’s the full-screen version, the actual fiddle – code and all(preview probably in tablet or phone mode depending on how big your screen is) is here.
An ASP.NET MVC demo with everything showed above in full code. The Hierarchical Grid here doesn’t use bootstrap so you can compare how very little difference there is in code.
There’s a Webinar on Designing for Responsive Design tomorrow, don’t miss!

Documentation - igGrid Responsive Web Design (RWD) Mode
Responsive Web Design Custom Mode Template Switching and Responsive Web Design Mode of the Grid with Twitter Bootstrap
Other awesome stuff: Ignite UI: What’s New in 13.1 HTML5, jQuery & ASP.NET MVC Controls
Go grab Ignite UI

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!

jQuery Grids and Responsive Web Design

[Infragistics] Damyan Petev — 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!

jQuery Grids with Multi-Column Headers

[Infragistics] Damyan Petev — Tue, 12 Mar 2013 03:32:00 GMT

If you’ve been reading the latest blog about the Column Moving feature of the Ignite UI Grid I’ve briefly mentioned Multi-column Headers. Well, just in case you missed it – that’s a fairly recent addition too! Through a very simple (and logical I think) setup of columns and layouts, this feature allows for visual and sometimes functional grouping of column headers under a common parent.

While on its own it might be mostly a visual thing, having other parts/modules of the Ignite UI Grid and Hierarchical Grid being aware of it, it can have some really interesting interactions. These might not be part of the actual widgets code, but they are a by-product of having column headers grouped while using other features. And below I’ll be throwing some more feature names at you for reference in one place.

Lastly if you are in for a quick start with the whole toolset and related concepts you can Get Started Learning Ignite UI Today! I could not resist the awesome contained in there and now, with the shameless plug done with, let’s move on to the basics of the feature.

Quick Start

After all you need to start somewhere and if you are like me and just straight to the API to check out capabilities, you are in for a slight shock. As it stands, the Multi-Column Headers widget doesn’t really offer much. So how do you set it up? Well it all becomes very reasonable when you begin to thing about the widget itself as an on/off switch (which is exactly what it does) and the column definitions are where they always were.. in the column collection! You can simply add one that has a collection on it’s own assigned to its ‘group’ property. Inside you can have more columns with groups and so on – the feature should allow for virtually unlimited nested headers. Then you also have some additional properties like a key and row span. A partial snippet with the ASP.NET MVC Helper (important lines are 5 and 6):

 @(Html.Infragistics().Grid<MultiColumnHeaders.Models.Department>()
    .Columns(column =>
    {
        column.For(x => x.DepartmentID).HeaderText("DEP Id");
        column.MultiColumnHeader("Dep").HeaderText("Dep")
            .Group(innerColumn =>
            {
                innerColumn.For(x => x.Name).HeaderText("Name");
                innerColumn.For(x => x.GroupName).HeaderText("GroupName");
            });
    })
    //...
 

And it’s as simple in script(line 9):

 $('#grid').igHierarchicalGrid({
    columns: [{
        key: 'DepartmentID',
        dataType: 'number',
        headerText: 'DEP Id'
    }, {
        key: 'Dep',
        headerText: 'Dep',
        group: [{
            key: 'Name',
            dataType: 'string',
            headerText: 'Name'
        }, {
            key: 'GroupName',
            dataType: 'string',
            headerText: 'GroupName'
        }]
    }],
    //..
 

For the above layouts to work simply add the “MultiColumnHeaders” feature to the respective collection:

 //....
.Features(feature => feature.MultiColumnHeaders().Inherit(true))
//  ---- OR -----
 features: [{
            name: 'MultiColumnHeaders'
        }],
//...
 

You have two options here as usual when it comes to the Hierarchical Grid – you can define the feature in the parent’s collection and allow inheritance or add it to the specific layout. Overall you can check out the igGrid Multi-Column Header topics in our help they already contain a fairly detailed guide. Or you can also refer to the samples and demos section below and learn by example :)

Not so fast!

First off, let’s have a little bit of understanding of what exactly the feature does it modifies the markup in the THEAD of the Grid table. The Multi-Column Headers feature provides out-of-the-box alignment - as you’d expect much of it revolves around figuring out the perfect way to align actual column headers in there – setting “colspan” and row spans, the latter you can tweak (more on that below). The only required setting really is the group collection, really. Well, I guess the header text is also really nice to have, because you’ll end up with header saying ‘undefined’ otherwise.

Then there’s also the key. Unlike your usual column settings, the key in this case doesn't correspond to a data property. So why would you need it? When you don’t assign a multi-column header a key(which doubles as identifier) you will be stuck with whatever the grid comes up with on its own. That means that the identifiers will be generated (incrementing number id) and these don’t always get assigned as you’d expect. Furthermore, perhaps you’ve seen some methods – particularly with API that manipulate columns like Hiding and Moving – that do accept multi-column identifiers/keys. Lacking a key can sometimes cause odd behavior, so it’s best if you consider it required as well. In addition, you don’t want to be missing on the opportunity for easy header targeting:

When you define a key the headers will also be assigned id-s (combination of the Ignite UI Grid’s Id and the column’s) that you can use for super fast and easy targeting. This puts those headers in line with the data-bound ones you see with “data-isheadercell” attribute set to true.

The good and evil row spans

The ‘rowspan’ property is a direct reference to the underlying table cell property, however the feature itself figures out the alignment of cells in rows (in order to have them span and align the way you’d expect rows sometimes end up containing both data bound and group headers). So there are some ‘gotcha’-s right here. For example take the case below (some columns are hidden and other squished so they can fit in the shot) where we set the “Record Info” group header from it’s original single row span to two in order to push its child column lower and align them with the rest.

Notice how the intention to merely align all the ‘actual’ headers in a neat row resulted in enlarging the entire header table. Because this aligned the last two column headers with the rest in a neat row, they really actually ended up in the same table row in markup. And since those were slightly bigger with more text the row expanded to fit them, causing the stretch. Also if you define row spans for columns that don’t have anything else to take up the space or not enough space to fit the rest you can end up needing to compensate elsewhere to avoid skewed layout. Generally, I’d suggest relying on the grid to do that for you.

More on the API

As you can see duly noted in the documentation the feature’s own getMultiColumnHeaders should be used in order to get the headers and their groups, as if you get the igGrid widget columns collection using $(“.selector”).igGrid(“option”, “columns”) you will get the ‘actual’ ones only – no group hierarchy.

It’s a similar case with the hierarchical grid, but for different reasons. You can actually pull the column options as usual and they will contain the group headers and their children, however that’s only good if you need to check out the header hierarchy. For the additional info, such as col/row span, identifier or level you should again rely on the getMultiColumnHeaders method.

There’s another method, that oddly enough the API is missing, but the documentation doesn’t and I figured it’s good to mention – it’s called "renderMultiColumnHeader" and it takes the very same column collection you’d provide for grid initialization. With it you can change the Multi-column headers’ arrangement in runtime or even define columns without any – just keep in mind it costs a grid rebind. It’s fairly simple to use too:

$('#Grid1').igGrid("renderMultiColumnHeader", [{
    key: 'DepartmentID',
    dataType: 'number',
    headerText: 'DEP Id'
}, {
    headerText: "Dep",
    group: [
    //...
    ]
}]);

There are other setting you’d normally see in the API that are shared for all columns (less so with the ASP.NET MVC helpers) that you might set, but will be generally ignored (templates, formatters and such don’t make much sense there). There are some that would, but still will not apply – e.g. the width property. The width of the multi-column header is determined by it’s group and in order to define width for it you just have to set it up on the child columns.

Styling

The feature applies a single specific class(“ui-iggrid-multiheader-cell”) to the headers you can target with CSS. This allows for specific styles to differentiate the group headers from the rest, which is something that I think the default Infragistics theme needs. You can do anything really, but I decided a subtle underline will do quite nicely (which I totally stole from the Modern UI theme!) so with the following style:

.ui-iggrid th.ui-iggrid-multiheader-cell {
    border-bottom-color: #2cbdf9;
    border-bottom-width: 1px;
}

You get something similar to this. You can even use some pseudo-classes to alternate between styles in case you have more groups, which I’ve also done in my samples so check them out below.

Feature interaction

I’ve already mentioned in my last blog Column Moving is playing well with multi headers. And as you can imagine the parent headers can also be dragged in order to move all their children at once. So what else interesting?

With the Hiding Feature you get a nice icon on the header to use to hide the entire group and parent will go away if all nested columns are hidden. You can also simply set the ‘hidden’ property of the column to hide it by default and that part doesn’t even require the respective feature to work (but it will lack UI and Interactions to show the columns without).

Both features’ API methods that perform column operations will also accept multi-column header identifier in place of the key.

When Resizing the user can interact both with individual columns or with their group header both leading to a satisfactory reactions – resizing nested columns will modify the parent’s width and vice versa.

In terms of UI, both Hiding and Column Moving produce their distinctive header icons for interaction, as seen on the topmost image of the blog. Unlike data-bound columns that accumulate additional features in a single gear icon, the group ones doesn’t support more than the two above and therefore don’t get a feature chooser! That might change as more features that make sense to be bulk-performed are added to the Grids (*hint hint* might happen very soon too).

Resources

Get Started Learning Ignite UI Today! (yes, yes, again!)
The Help topics for Multi-Column Headers
And the configuration topic for the Hierarchical Grid
Grid Multi-Column Headers sample
Hierarchical Grid Multi-Column Headers sample
My ASP.NET MVC demo with various definition types for both flat and hierarchical Grids, features and styling. Views using the helper require at least the free trial version of Ignite UI installed – get it from the link below!
JSFiddle demos for igGrid and igHierarchicalGrid
Grab yours:

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

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

Ignite UI jQuery Grid Column Moving

[Infragistics] Damyan Petev — Fri, 22 Feb 2013 16:47:00 GMT

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

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

Getting started

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

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

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

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

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

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

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

Control

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

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

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

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

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

Notes, tips and tricks

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

The hidden settings

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

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

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

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

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

Multi-Column headers and hierarchy

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

Performance

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

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

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

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

Making use of events to enhance functionality

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

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

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

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

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

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

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

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

Resources

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

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

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

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

Financial charting with Ignite UI

[Infragistics] Damyan Petev — Wed, 13 Feb 2013 19:50:00 GMT

Or should I say “How to deliver charts for Technical analysis” and then throw in a little bit of understanding for a good measure. So, we are technical people, no? Then technical analysis shouldn’t sound so distant? Yeah, well, in the field of finance it kind of does… It’s used for forecasting the direction of prices, a discipline in security analysis (probably not the kind of security you would think about first). There’s also quite a bit of theory behind this, but put shortly it’s about making assumptions based on study of past prices and volumes. Still, being able to understand what you are doing is essential, so I’ll try to cover just a little bit – I have the feeling many don’t quite get those and will find it rather interesting. The analysis involves a whole set of values (business opening and closing prices, high and low reached, all for a set time frame and often complemented by volumes). That much data calls for more specialized types of series. Fortunately, the Ignite UI Data Chart has got you covered! Well, at least the technical part, so you can make the finance crowd happy and leave the analysis part to them. The chart control comes with the Financial Price Series in OHLC mode and Candlestick mode and the recent addition of over 35 financial overlay and indicator series to support those.

Get to know the Financial Price Series

These series are a combination of line and bar charts, where each point in the chart is actually a representation of all those 4 price values. But first things first, the data – all the four major values have to do with stock trading price – the high and low are pretty self explanatory, while the open and close are the trading prices agreed upon at the start and end of the business day or whatever time frame is to be plotted. These are all nicely indicated in a single OHLC bar:

It has a certain continuity to it so I figured it’d be nice to start with and easy to understand. Besides the bar like OHLC, another way of representing stock trades has been the Japanese Candlestick. While they provide the same information, the difference is in the degree of focus on some or all aspects.

Bulls and Bears

It’s beyond me how exactly these two animals came to represent market sentiment / trend, which is exactly the reason to use such type of charting - because “all boats float or sink with the tide”, they say, and also "the trend is your friend". The bull and bear describe upward or downward market trends and with them come the bullish and bearish bars in the charts that help identify trends.

The OHLC has the open and close on specific sides of the high-low bar, so all the data is equally visible, but there is no immediate focus on whether the open was lower than the close or the other way around (note the Ignite UI Data Chart provides color-coding for bullish/bearish). The Candlesticks, on the other hand, put a lot of emphasis on the opening and closing prices and make it quite easily visible and accessible – with both OHLC and bearishness/bullishness explained this should be pretty clear:

The candlesticks’ body is symmetrical, but to indicate bullishness it is empty (or differently color-coded), while the bearish is filled (or just darker):

Again it's the same data, but rearranged and it's a matter of preference, really. There's also a nice technical side effect from this as I'll describe below. In addition, Candlesticks are much more complicated than this - what I pictured above are actually a Big White and Big Black Candle patterns, but there are the most simple and a lot more advanced patterns used to read/predict trends and if you are interested check out this Candlestick pattern article.

The technical stuff

After the brief theory, we reach the part most of you would be interested in. So the series accept high, low, open and close values in the respective member path property. The bonus I mentioned about the data being equal between OHLC and Candlestick is that you can effortlessly switch between them – there’s a reason why they are two modes of the same series - all you have to do is set the “displayType” property to either “candlestick” or “ohlc” and the chart will automatically react to changes! An example switch code:

$("#priceChart").igDataChart("option", "series", [{
    name: "stockSeries",
    displayType: "ohlc"
}]);

Following in the footsteps

While looking for a nice data source for my sample I looked into the amazing Finance Dashboard showcase (you can also download the WPF Finance Dashboard). I loved the sample and I wanted to at least partially create something similar for Ignite UI, since the Ignite UI Data Chart comes from the XAML control. Oh, and I totally stole the sample Yahoo! Pipes source, which if I may add is pretty awesome! So with the data out of the way, setting up a chart is rather easy:

$("#priceChart").igDataChart({
    dataSource: ds.dataView(),
    axes: [{
        type: "categoryX",
        label: "Date",
        name: "xAxis"
      }, {
        type: "numericY",
        name: "yAxis"
    }],
    series: [{
        type: "financial",
        displayType: "candlestick",
        closeMemberPath: "Close",
        highMemberPath: "High",
        lowMemberPath: "Low",
        openMemberPath: "Open",
        xAxis: "xAxis",
        yAxis: "yAxis",
        name: "stockSeries",
        title: "Price Data",
        trendLineType: "simpleAverage",
        trendLinePeriod: 50
    }]
});

As the Financial Series are often displayed with trend line from a variation of a moving averages, do note that as above the “simpleAverage” and the others (exponential, modified, cumulative, weighted) are all moving averages right there at your disposal and can have their period customized.

I also added that accompanying Volume series below in a similar way and a third chart with indicators. Then I figured it’ll also be nice to have some sort of synchronization between the charts to imitate that zoombar’s functionality and event though it’s not quite the same thing, you can easily manipulate them via the World Rectangle. I chose to just use an event from the main stock chart, but this can easily be controlled from a range slider or something similar as well:

$("#priceChart").igDataChart({
            windowRectChanged: function (evt, ui) {
            // Keep the other two charts in sync
                $("#indicatorChart").add("#volumeChart").igDataChart("option", "windowRect", {
                    left: ui.newLeft,
                    top: ui.newTop,
                    width: ui.newWidth,
                    height: ui.newHeight
                });
            }
        });

As a note, this event is fired a lot so if you intend to use it I suggest you also use the “windowResponse” set to "deferred" on the controlling chart. Careful with cross-linking charts this way – setting new values will also fire the respective charts’ events, just so you know.. and yes the chart is smart enough to ignore values if nothing is really different, but still be mindful.

Update: Easier and better synchronization

Following up a tip from one of our Chart experts, Graham Murray, it turns out I completely overlooked the fact Ignite UI Data Chart also has built-in synchronization! In this case the above code can be completely replaced by these lines:

$("#priceChart").igDataChart({
    syncChannel: "channel1",
    synchronizeVertically: false,
    syncrhonizeHorizontally: true
});

You set the other charts to the same sync channel and settings and you are good to go! This takes care of all the possible issues with the method above and also provides a cool bonus – the zoom preview shown on the main chart (when response is deferred) is also displayed on the other sync’d charts! The JSFiddle demo has been updated, check the link below!

Notes and tips

I actually have a decent set of other “good to know” stuff along the way, so here’s some:

Update: The “resolution” series property has an interesting effect on the Financial Price Series – it determines how many records can be coalesced into a single Candlestick/OHLC bar when there isn’t enough room. Of course, details are revealed when you zoon in. This can be very awesome for huge data sets or really tiny spaces (hello mobile dashboard!). There’s an alternative demo right here.
Don’t shy away from using the power of the underlying igDataSource to mold the incoming data to your needs and reduce potentially hulking requests to get filtered sub-sets. As you will be able to see in the demo I’m pre-sorting the data as it comes with the latest first in the array, which would totally make for a backwards plotting if not sorted. The igDataSource got the tools for the job.
The “outline” brush property will affect both the outline for candle stick and the shadows (they are drawn in the same stroke with the outline, just so know). However, the outline has nothing to do with the OHLC bars – they, like other line-based series, have no outline.
The OHLC bars are, however, affected by the “brush” – in both series the main brush color will be used to indicate bullish candles(the fill)/bars. If you want both empty candlesticks and the ability to switch between modes on the same series, make sure you change the brush color when going to OHLC as the bullish bars there might be left almost invisible!
In both series, the the “negativeBrush” property color will be used to indicate bearish candles(the fill)/bars.
All the brush properties can be altered at runtime just like changing modes, you can also style the chart using themes!
The Financial Indicator/Overlay series are actually 36 in number - an impressive number to chew through. Keep in mind each has a set of required data-binding properties(out of the the already familiar High, Low, Close and Volume) and the some. I’ll go in much greater detail below.
Note that with the Data Chart you have freedom to position your indicator series – either as separate charts, or with the main Financial Series using multiple axes.

Financial Indicators

“These indicators are used to help assess whether an asset is trending, and if it is, the probability of its direction and of continuation. Technicians also look for relationships between price/volume indices and market indicators”. Often found above, below and on top of the financial charts. They can be used the same way as any other series found in the igDataChart control and require specific data mapping to stock price values and stock volume. That last part is where it gets extra interesting…

The Ignite UI Data Chart does inherit most of it’s features from the XAML Data Chart, so many things true for the latter and also true for the jQuery one. This means you can also check out the XAML documentation or possibly re-use previous experience with the control. I have, however, went the extra mile on this one to provide you with a complete reference (Ignite UI jQuery API style) of all the Financial Indicator and Overlay series types, descriptions and their relevant data-binding and setting properties! I give you the:

Ignite UI Data Chart Financial Indicators and Overlays (WARNING! Massive, huge table Inside!)

After all, it 36 series and I slightly failed on finding better arrangement, but hey – you are welcome!

Also note all the specific properties like periods and such have defaults in case you are wondering what happens if you skip them. For the demo I picked just a few series with a period (usually defaults to 14, with some exceptions I’ve marked in brackets) so I can safely share settings and let you play with them.

Oh and the full view?

It’s not quite like the Dashboard I was after, but this is as far as I had the time to get it to and there’s still plenty of polishing to do. At the very least this is all real data (one year span) and functional enough to play with and give you a good idea what you can do with the Data Chart.

Resources

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

Documentation for the igDataChart
Financial Series sample. You can also check out this sample with all Financial Indicators available!
The Demo Finance Dashboard is on JSFiddle (link is to the result, as this is meant to be viewed in full screen). Top right for a link to the edit page. And in case you want to save this one there’s a pieced-together html file right here. Yeah, no ASP.NET demo, at least not yet.
Update: Alternative demo with charts coalescing up to two weeks of data in one bar to fit in smaller spaces and expanding to normal when zoomed.
And finally.. Go get yours:

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

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

PHP Server-side wrapper for the Ignite UI File Upload

[Infragistics] Damyan Petev — Wed, 30 Jan 2013 23:53:00 GMT

I’ve been recently having plenty of fun shifting platforms like a mad man and I feel it’s time to share some goodness with you all. Let’s have ourselves some PHP (and even if that’s not your thing you still might want to check out the last part)! While we still stand behind our statement that the Ignite UI controls can run everywhere and are server-agnostic, there should really be a tiny asterisk on that one. And what it should state is… well, that you would need custom server side logic to use the File Upload as it only comes with ASP.NET support (handlers for IIS) out-of-the-box. With that in mind, it is true that the control itself is still 100% client-side jQuery, but highly dependent (for now) on communication with the server (I’ll explain why in a bit). So I’ve been on this PHP wave going for Ignite UI Controls with WordPress (for which I’m still gather opinions by the way!) and I thought it would be an awesome idea to have proper PHP wrappers for all Ignite UI controls to ease that up and also to be usable as standalone in other apps. Pretty much I’m making baby-steps towards the original goal (bear with me) and I thought I’d start with something useful like the File Upload:

Take into account that the best part of the control is the AJAX multiple file upload and the progress tracking. First part is taken care of on the client, but the latter needs serious back-end push in most cases where the latest XHR is not supported and I’ll mention those last, for now assume you can’t rely on that. I figured the File Upload progress can’t be that hard – boy, was I in for a ride ..

Limitations, limitations and then some..

So how is file progress handled without client-side access? Well, you can say it takes a lot of communication For the client side to provide a decent experience it needs to know the size of the file, and sadly no good browser will disclose such information to JavaScript (and thus jQuery). So what do you do when only the server can know the actual file size? You ask, of course! The default way of doing so is to fake the file post with special hint to the server (so the backend can grab the size) and reject it. That, however, only flies when you do have access to the actual incoming stream and control over it. The case with PHP is not such – files reach your code ready-to-use. Essentially all you have to do is pick the files you want from the $_FILES superglobal and move them to where you want them saved, for example:

$sucess = move_uploaded_file($_FILES["fileInput"]["tmp_name"] , 'upload/' . $_FILES["fileInput"]["name"]);
echo ($sucess ? "Stored " : "Failed to store") . "in: " . "upload/" .  $_FILES["fileInput"]["name"];

Pretty simple! But PHP’s simplicity is both a blessing and a curse - it will upload files to temporary folder and assign temporary names for you, and sadly the actual PHP script you want to use to handle file uploads will only be executed after the file has been completely uploaded or an error has occurred. You can see the problem here, right? Imagine a 100MB file is to be uploaded..so wait for how long to get the size? And the whole file just to grab the size? And then dump it and upload again? It’s just pointless when you can’t immediately cancel the upload. So no initial size will be available, fine, but progress, what about that? Well cue the drums, in comes PHP 5.4 giving you a fairly usable way of tracking just that. The inner handling of the actual file upload will kindly set you some info in a special variable in the $_SESSION so you can check how the file is coming along. So far so good, you’d imagine, but as long as there’s actual progress going on being posted to one point, another would be best to be constantly polled. That ensures quite the additional work to synchronize between those.

There’s more - remember the part where the file actually makes it all the way to the server, before the realization it’s not welcome happens? Yeah, that also means the progress you are showing to the client is the temporary file being transferred, and only at the end of it will you know if it was successfully saved.

So you get no initial information on size and the outcome is only available after a short wait time? PHP also offers an additional MAX_FILE_SIZE field (see http://www.php.net/manual/en/features.file-upload.post-method.php) which truly confused the living hell out of me. I’m far from the illusion it’s a browser hint ( I mean I think we can almost take XMLHttpRequest Level 2 (and File API) as granted soon, as it looks like it’s already stable and spreading to even IE10!) so I would assume that fields feature is similar to the actual Session progress field and it somewhat is. While it says it’s supposed to save “users the trouble of waiting for a big file being transferred only to find that it was too large” from my tests(PHP 5.4.7) I find it doesn’t really abort the upload, but the session upload progress does hang. //end rant

While I have included this as optional functionality, it should be noted this is easily manipulated and while not very functional, it should definitely not be trusted to restrict the size. I could say the progress hang has the potential with some additional logic to be used to detect when the file has gone over the limit and cancel it(from either side), but I haven’t came around to doing that just yet.

Oh yeah, finally you have the session info disappearing from the superglobal as soon as the file is done loading, which is because of the auto-clean. That is again simpler to handle, but harder to manipulate. The thing is, it’s highly recommended to have it on, so I won’t ask you to do otherwise, instead more of the guessing game!

Workarounds, hacks, tricks, etc.

First things first, the settings (in the php.ini or some other way, depending on the hosting and what not..) upload_max_filesize should be set to something reasonable (keep in mind as default it’s just 2MB) and it should be less than post_max_size! Note that there is no workaround for those, other maximum sizes you see are ‘soft’ limits. Note that the Ignite UI File Upload will still do multiple requests for separate files, so the maximum post size can be almost the same as the maximum file size, you don’t need to worry about that. Also, session.upload_progress.enabled should be on (it is by default) and I've left the rest to defaults as well.

So to have a working file upload with PHP on the back-end some patching up of the Ignite UI control was required. Since the actual progress requires the special hidden field before the input (of type file) and we can’t really fake-post here – I have a handler removing the actual file input when registering the file with the server for file size (which for the reason is always initially 0) and adding the special hidden field(s) when the actual post does happen. This is done through scripts emitted from the wrapper. What they also do is play yet another trick on the widget and fix the size in the file information once it becomes available (which is only after the upload has actually started) so the user experience can be mostly unaffected. Oh and the auto-start upload feature totally plays on every weak side of the PHP handling – skipping the initial register and directly going for posting the file and asking for status – which again is unfortunately not really ideal since I can’t map the key from the post with its file name before the upload has ended…therefore requests with the key would return nothing. So I register the file before the widget gets a change to submit in that case, which might not be ideal, but does the job.

One last touch is trying had to maintain a minimal footprint in the session storage by deleting keys that have finished/threw error. However, the equivalent ASP.NET wrapper only holds to such information for a given period of time, which is quite a cumbersome task with PHP, so when you register(pick) a file, but then remove it - no more requests are made with that key and it sticks around. Here’s an optional way to deal with that :

$(document).delegate("#igUpload1", "iguploadfileuploadaborted", function (evt, ui) {
    if (ui.status == 0) {
        var key = $("#igUpload1").igUpload("getFileInfoData").filesInfo[ui.fileId].key;
        $.ajax({
            url: "uploadHandler.php",
            type: "GET",
            data: {'key': key, 'command': "clear" }
        });
    }
});

This is totally optional, of course, you could implement something better.

Usage

Why PHP wrappers , you’d ask? Well, so you can have this oh-so-very-nice experience inside your IDE:

Having pretty much every setting easily available and mostly described (I might’ve failed here) should make using the Ignite UI widgets a joy! And hey, while at it, figured it’s also nice to have the Loader PHP-ready as well! And the options on both classes are identical to the actual jQuery API (so you don’t need PHP specific documentation and so I can serialize them easily ) .

Note you still need to include jQuery and jQuery UI as usual, and then:

<?php
include_once 'IG/igLoader.php';
include_once 'IG/igUpload.php';
include_once 'IG/config.php';        
$igLoader = new ig\loader\igLoader("http://cdn-na.infragistics.com/jquery/20122/latest/css/", "http://cdn-na.infragistics.com/jquery/20122/latest/js/", "igUpload");
echo $igLoader;
$igUpload1 = new ig\upload\igUpload("igUpload1", "upload.php", "uploadHandler.php");
$igUpload1->allowedExtensions = ig\upload\Config::$allowedExts;
$igUpload1->mode = ig\upload\UploadMode::Multiple;
$igUpload1->maxSimultaneousFilesUploads = 2;
echo $igUpload1;
?>

The upload handler is the endpoint for requesting status updates, handled by the class I’ve also included. And the third main piece of the package is the upload module that handles file posts. The config contains:

allowed extensions - set to the Upload control above and also verified by the module when saving.
accepted Mime types – again verified by the module when saving.
file upload path – this is the place the module will try to save to, make sure it exists with write rights
max file size – used by the module, can also be assigned to the Upload control, but as explained above its uses are very limited.

And one last thing - security..yeah. it's that part again... well I'm no PHP master and many of the enforced restrictions are based on information that comes from the client. Therefore, they can't be trusted and just in case I've missed something(probably have) you can use the “fileUploaded” event to apply any other checks you want. So in the “upload.php” you can have:

<?php
 include_once 'IG/igUploadModule.php';
 $uploadModule = new ig\upload\igUploadModule();
 $uploadModule->fileUploaded("fileSaving");
 $uploadModule->HandleRequests();

function fileSaving($sKey, $fKey){
     $sessionInfo = $_SESSION[$sKey];
     $fileInfo = $_FILES[$fKey];
     //check if file should be accepted
     return true;
}
?>

The function will receive two keys – one for the session info and one for the file info in their respective globals, so you can have the final say if the file should be saved by returning true or false.

Also note that while a blacklist is generally recommended I find a small whitelist to be much more restrictive and closer to the existing control behavior.

The future looks HTML5 bright…

… but not FLASH-y – and by that I mean HTML5 specifications are actively evolving to make any and all client side plugins a thing of the past and file uploading and general file access have been long overdue. Now, though, HTML5 (well, technically, XMLHttpRequest Level 2 is not part of HTML5, but still…) is to offer file access as well as upload progress - pretty much everything you need from the browser (one of the sides that already inherently knows the upload status, but never liked to share so far). So in that sense, I would like to proudly announce that all the hacks and what not are soon going to be completely unnecessary – the Ignite UI File Upload is going HTML5 mode with the next release (that is 13.1) so there will be no more file size requests and no more status requests!

But seriously, that’s not completely true – as I mentioned the standard is not finished and the browser support is not that broad. The point is that the Upload widget itself will fill in the gaps - and the current implementation of the upload module will still verify and accept files just fine, but there will no longer be requests for status. There will be some minor adjustments required to optimize it, but in a up-to-date browser your File Upload widget will produce much less traffic!

Try the PHP File Uplaod with Ignite UI for yourself and if you see somewhere I can improve something or you find a bug do let me know. PHP 5.4 is required. Also once you can get your hands on the new File Upload I will try to provide the PHP wrappers updated for 13.1. Perhaps some WordPress plugin and the same treatment are incoming for other controls (I also might be totally overdoing the promises right now ), but in the meantime, grab your version of the awesome Ignite UI toolset:

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!

Using jQuery UI Controls with WordPress

[Infragistics] Damyan Petev — Thu, 10 Jan 2013 16:54:00 GMT

We’ve stated time and time again that the Ignite UI controls based on jQuery and jQuery UI are pure client-side scripts that are completely server agnostic (meaning they do not depend on the back end). So we keep saying you can use them everywhere, yet time limits the number of platforms we can cover with guides and such. There has been one article on Using jQuery Grid with PHP pretty much. We figured it might be a good time for some more. PHP itself is so tightly integrated with web content (petty much described as HTML-embedded) that every html snippet and sample you find is yours for the taking. Considering that along with JavaScript, they are the two most widely spread scripting languages, I would also assume if you do Web with PHP you probably have a decent experience with both. You can tell

It’s all good and merry when integrating with your own site’s internals, but what if you are developing for something like WordPress? It’s extremely popular and powers a decent chunk of the top websites. The thing about WordPress is that perhaps part of its popularity is due to the fact that it provides a very powerful, but at the same time very user-friendly platform to build sites on – and by that I mean a very easy interface for non-programmers, extensive admin panel, widgetized themes and a plethora of extensions. That also means that if you are in the role of the programmer you have a lot of demand and a platform to develop for

General

I think everyone are/will be quite pleased with the ways you can add functionality to WP – they all have their strengths in certain areas, but more on that later.

Let’s start with the general concept of running an Ignite UI widget in a page – you need jQuery, relevant jQuery UI and Ignite UI scripts (an awesome place to get a list of requirements for each control is to visit the Ignite UI API Reference where each control’s home page gives a detailed ordered list of dependencies or sink yer teeth in the Documentation). As you probably already know the reason I mentioned PHP is because WordPress is built with it – that means you could probably just go and output whatever and wherever you like. However, the beauty of it is that you don’t have to – WordPress kindly offers to handle a lot of that for you:

Don’t just output script tags! Use the wp_enqueue_script() function instead – it has jQuery and jQuery UI scripts already registered, so you can simply use something like:
```
wp_enqueue_script('jquery');
```
There are a ton of plugins or widgets that use jQuery already and the great deal about this is that the function will not add the library again if it’s already been included - trust me you do not want to double it, I've seen that cause errors, plus you don’t really want to try and check for yourself either, so please use this instead. Also provided are a number of additional settings to provide source location for the script and even define dependencies. Preferably save the Ignite UI control initialization scripts with whatever options you need in a script file and also queue it in the same way.
On a side note, there’s also wp enqueue style().
Be mindful where you include - Note that usually, scripts are added to the head of the document, depending where you do the call, however WordPress will allow mid-page calls to the function that will output the scripts in the footer instead. There’s also option to include in the footer. Use the available action and filter hooks to properly initialize those. Also make use of is_admin()to skip unnecessary script loads in admin panel, unless that is your goal.
No conflict – in the queue function reference there’s a chapter on the jQuery noConflict more – please be aware of that if you are using the default library. Also, in case you are wondering – Ignite UI widgets are indeed properly wrapped in a self-executing function to guarantee safe usage of ‘$’ in private scope. So basically you should only worry about your own code.

What are your options?

So how can leverage the extensibility WordPress provides? Do think of the following as concepts, I might end up doing some, but for now everything below is strictly an idea.

Shortcodes

I think those are by far the easiest to get going ( plug they are decently user-friendly) and WordPress gives you a Shortcode API. As you can see there a short code will be kind of good for adding Ignite UI widgets where you don’t require a lot of settings from the user (you provide most of the defaults) or the control itself is fairly easy to set. That is because, while the API does provide a method to have attributes, asking someone to enter 20-ish or more of them is just wrong. An example for the igRating can look like this:

[ig-rating value="1"]

And through the add_shortcode() you assign a function to this tittle that WordPress will call to replace the tag.

On the flip side, short codes can be added anywhere (pages, posts) so you don’t have to worry about proper hooks for those. The also tricky part is that the attributes don’t do camel casing, therefore you won’t be able to match the Ignite UI widget settings exactly and directly pass the encoded the attributes as options for it.

There are a lot of References at the bottom of every WordPress documantation page (which totally rocks!) so check those out, and here’s a bonus from me with an awesome video guide - WordPress Shortcode API Crash Course.

Widgets

These are also pretty popular, as their main goal is to add content and functionality to sidebars of "widgetized" themes, however since that just means sidebars are registered, so there are ways to add a ‘sidebar’ to your posts and pages (by making a new template, and then using it for new ones). Widgets are not quite as simple to implement, but again there’s Widgets API to the rescue. You have a base class to extend and a few functions to override. The end goal of course is to have something like this in the admin panel:

WordPress will be extremely kind to handle all the database work for you – serializing back and forth, and calling your functions with the ready-to-use arrays. While that totally rocks, just how many settings fields do you think would be acceptable to stick in there? I’d say not too many or you are going to have a really poor user experience. So again much like the short code – good for not-so complicated controls or when used with plenty of defaults you provide instead.

Plugins

And we reach to the most capable option to develop with – as stated the plugins “can extend WordPress to do almost anything you can imagine”. Plugins Docs can be your starting point, but there’s one that is even more interesting – the option register your own settings page with plugin options via the Settings API and have it appear in the admin panel like this:

And as you’d expect WordPress will abstract away the database plumbing – much like the Widgets options you can output a settings form and the names of inputs will become attributes of the options object you can later on request. The nicest part is that you get a whole page for your control settings ad you can really go wild here – tabs and what not and as many settings as it makes sense.

You will have to worry about hooks and what not, but I’m guessing it can be worth it.

What do you think?

So what do you think would be the most appropriate way to go with this? Do you thing that different solutions fit different controls better? Looking at the Ignite UI toolset, imagine a control being available in WordPress as whether a short code, widget or plugin – as an user, which one are you more likely to use and how? What would you do as a developer?

I’d love to hear some thoughts, so leave a comment down below or @DamyanPetev. If you have already developed anything with Ignite UI and WordPress we’d love to see your work and if you haven’t but you are interested, go for the WordPress documentation and grab yourself some UI fuel from:

Also stay tuned to see where this ends up!

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

How to add updating to the Ignite UI Tree’s Drag & Drop

[Infragistics] Damyan Petev — Thu, 03 Jan 2013 16:17:00 GMT

As it turns out the Drag & Drop feature is like the gift that keeps on giving – new year and new enhancement to the functionality! May be because the Ignite UI Tree is flexible enough or maybe because the functionality itself is based on simple Add and Remove API coupled with jQuery UI interactions, both of which are easy to understand, manipulate and extend :)

I’m thinking once you allow a user to move nodes around at one point you might come to the conclusion that some of those changes can be persisted. And as with most user actions - no surprise here! - mistakes do and will happen. That gets us to yet another point – why not add functionality for the user to undo and redo Drag & Drop operations? Indeed, why not!

And while it does require some custom code, as we are trying to make this interaction feature into an editing one, which is not how it is intended in its current implementation. On the other hand, the custom code is heavily reduced as we have a number of building blocks right there at our disposal. So far we’ve been looking into the usability side in the previous post with Tips on Drag & Drop with the Ignite UI Tree and some basics of the Drag & Drop with the Ignite UI Tree – make sure you check those out as we’ll be building on top of some of the knowledge gained and this time dive into the functionality. I’m not saying the enhanced selection and Load On Demand were not functional, they were, but if you look at it this way – they were tweaks based on the Draggable and Droppable nature implemented by the control. Now remember the other API part? That’s our target now..

Leaving a trace behind

I’ll try not to bore you too much with Add/Remove ‘getting-started’ stuff, as someone else was kind enough to do that – check out the Adding and Removing Nodes Help topic and there are some online samples for those API methods too! The thing that matters the most to us is that those operations create transactions in the underlying data source log and that Drag & Drop uses them. Essentially, we already have a history of the node moves, all you have to do is send it and provide server-side logic to handle the changes. The only thing to keep in mind is that a drop actually calls both methods – removing the original node and adding it to it’s new place. That in turn equals two transactions per drop, rather than one.

The tree also provides an update URL property to set to an endpoint to send transactions to (I’ll use the a similar Tree as the last two blogs for simplicity, again with Northwind’s Categories) :

 @model IQueryable<TreeDragDrop.Models.Category>
@using Infragistics.Web.Mvc;
@(Html.Infragistics().Tree(Model).ID("tree")
    .DragAndDrop(true)
    .DragAndDropSettings(d =>
    {
        d.DragAndDropMode(DragAndDropMode.Default);
        d.Revert(true);
        d.CustomDropValidation("customValidation");
    })
    .UpdateUrl(Url.Action("saveChanges"))
    .Bindings(binding =>
    {
        binding.PrimaryKey("CategoryID")
            .TextKey("CategoryName")
            .ValueKey("CategoryID")
            .ChildDataProperty("Products")
            .Bindings(b1 =>
            {
                b1.TextKey("ProductName")
                .ValueKey("ProductID")
                .PrimaryKey("ProductID");
            });
    })
    .DataBind().Render()
    )
 

Note line 11 where we set the action link. And, of course, this can be in client-only script as well:

 $('#tree').igTree({
    dataSource: '/Home/getData',
    dragAndDrop: true,
    dragAndDropSettings : {
        dragStartDelay : 100,
        revert : true,
        customDropValidation : 'customValidation'
    },
    updateUrl: '/Home/saveChanges',
    bindings : {
        primaryKey : 'CategoryID',
        textKey : 'CategoryName',
        valueKey : 'CategoryID',
        childDataProperty : 'Products',
        bindings : {
            textKey : 'ProductName',
            valueKey : 'ProductID',
            primaryKey : 'ProductID'
        }
    }
});
 

The controller action will have to deserialize the transactions and make sense of them. You have to do the same too I think, here a quick anatomy of a Tree transaction:

type – either "addnode" or "removenode" based on the method used. Remember you get both per single drop!
tid – generated ID of the transaction, useful for deleting a specific transaction.
tdata – all the important goodies are here : the ‘path’ of the node on which the method was performed and its entire ‘data’ record. It also contains a ‘parentPath’ for add operations.

As you can tell from the path we can assert from where the node was removed or to which parent was it added. Don’t forget to validate! That is the reason of the custom function, the Drag & Drop would usually allow much more that it might make sense to your model, especially so if you slack on the binding definitions. The function in this example denies a node from being dropped on it’s current parent or one of the other nodes with the same depth as they are all products. Saving the changes should generally be as simple as calling a method, however in this case, since the Add Node API method accepts multiple nodes (unlike the remove that is by path which is pretty specific), its path is an array instead of simple string. In a Drag & Drop scenario the add method will only be called with one value so you can go through the changes and normalize the path of the transaction (Drag & Drop would not add multiples) and unify them:

 function save() {
    var transLog = $('#tree').igTree('option', 'dataSource').root().allTransactions();
    //normalize transactions
    for (var i = 0; i < transLog.length; i++) {
        if (transLog[i].tdata.path instanceof Array) transLog[i].tdata.path = transLog[i].tdata.path[0];
    }
    //send to server
    $('#tree').igTree('option', 'dataSource').root().saveChanges();
}
 

Here’s how the controller action looks like:

 public ActionResult saveChanges()
 {
     var transactions = JsonConvert.DeserializeObject<List<JObject>>(Request.Form["ig_transactions"]);
     if (transactions.Count % 2 != 0)
     {
         return new HttpStatusCodeResult(System.Net.HttpStatusCode.Conflict);
     }
     for (var i = 0; i < transactions.Count; i+=2 )
     {
         // a single drag&drop produces 2 transactions - one removeing from the original spot and one adding to the new one.
         if (((string)transactions[i]["type"] == "addnode" && (string)transactions[i + 1]["type"] == "removenode") ||
             ((string)transactions[i]["type"] == "removenode" && (string)transactions[i + 1]["type"] == "addnode"))
         {
             // node was moved moved
             if ((string)transactions[i]["tdata"]["path"] == (string)transactions[i + 1]["tdata"]["path"])
             {
                 //merely a change in order, ignore (this will also skip category moves)
                 continue;
             }
             Product prod = JsonConvert.DeserializeObject<Product>(transactions[i]["tdata"]["data"].ToString());
             var product = db.Products.Where(x => x.ProductID == prod.ProductID).Single();
             int catId;
             if ((string)transactions[i]["type"] == "addnode")
             {
                 catId = int.Parse(transactions[i]["tdata"]["path"].ToString().Split('_').First());
             }
             else
             {
                 catId = int.Parse(transactions[i+1]["tdata"]["path"].ToString().Split('_').First());
             }
             product.CategoryID = catId;
             db.SaveChanges();
         }
     }
     // tell the data source we are cool
     Response.Write("{\"Success\": true}");
     return new JsonResult();
 }
 

As you can see I’ve pretty much made this for the Drag& Drop only (thus the validation if it divides by 2). If you use this in addition to programmatic calls to the Add/Remove API this will require more work ..or the result will be unpredictable. I’m also validating that each two are an add and remove combo and if the path is identical it means this is merely a change in order. Once that is done the actual business part is getting the Category ID (which is the parent part of the path when you have primary keys defined) and assign the one from the add operation to the product.

Go there! No, come back! Actually…

Undo that and redo this. It’s those ‘phew’ moments that always make me happy when I realize I haven’t forever lost something. This part however can be either pretty simple ..or somewhat harder to implement than updating depending if you care for nodes being dragged and dropped around under their parent – as in if you care for order. The reason for this is that the paths for nodes generated by the control instead indexes normally, will actually consist of the primary keys if you have some. However, primary keys will only reflect the node’s place in hierarchy but not the order. Since the igTree I’ve been using so far has primary key I figured going the extra mile for a better experience is totally worth it.

var redoStack = [], indexMap = {};

 function undo() {
    igtree = igtree || $("#tree").data("igTree");
    treeDS = treeDS || $('#tree').igTree('option', 'dataSource');
    var allTransactions = treeDS.root().allTransactions();
    if (allTransactions.length > 0 && (allTransactions.length % 2 === 0)) {
        var transactions = [allTransactions[allTransactions.length - 2], allTransactions[allTransactions.length - 1]];
        if (transactions[0].type == "removenode") {
            //always need to remove node before adding again!
            transactions = transactions.reverse();
        }
        var deferredIndex = {};
        for (var i = 0; i < 2; i++) {
            var transaction = transactions[i];
            var parentPath = ''; //for root node
            if (transaction.tdata.path.indexOf(igtree.options.pathSeparator) !== -1) {
                parentPath = transaction.tdata.path.split(igtree.options.pathSeparator).slice(0, this.length - 1).join(igtree.options.pathSeparator);
            }
            if (transaction.type == "removenode") {
                var parent = parentPath == '' ? igtree.element.children('ul') : igtree.nodeByPath(parentPath);
                var index = null;
                if (indexMap[transaction.tdata.path] < parent.children().length) {
                    index = indexMap[transaction.tdata.path];
                }
                igtree.addNode(transaction.tdata.data, parent, index);
            }
            else {
                //save index only after add
                var theNode = igtree.nodeByPath(transaction.tdata.path[0]);
                deferredIndex[transaction.tdata.path[0]] = theNode.parent().children().index(theNode);
                igtree.removeAt(transaction.tdata.path[0]);
            }
            treeDS.root()._removeTransactionByTransactionId(transaction.tid, true);
            redoStack.push(allTransactions.slice(-1)[0]);
            // also remove the two newly created last transaction..
            treeDS.root()._removeTransactionByTransactionId(allTransactions.slice(-1)[0].tid, true);
        }
        $.extend(indexMap, deferredIndex);
    }
}
 

 function redo() {
    igtree = igtree || $("#tree").data("igTree");
    treeDS = treeDS || $('#tree').igTree('option', 'dataSource');
    if (redoStack.length > 0 && (redoStack.length % 2 === 0)) {
        //always need to remove node before adding again!
        //this keeps the order:
        var transactions = [redoStack.pop(), redoStack.pop()];
        var deferredIndex = {};
        for (var i = 0; i < 2; i++) {
            var parentPath = ''; //for root node
            if (transactions[i].tdata.path.indexOf(igtree.options.pathSeparator) !== -1) {
                parentPath = transactions[i].tdata.path.split(igtree.options.pathSeparator).slice(0, this.length - 1).join(igtree.options.pathSeparator);
            }
            if (transactions[i].type == "removenode") {
                var parent = parentPath == '' ? igtree.element.children('ul') : igtree.nodeByPath(parentPath);
                var index = null;
                if (indexMap[transactions[i].tdata.path] < parent.children().length) {
                    index = indexMap[transactions[i].tdata.path];
                }
                igtree.addNode(transactions[i].tdata.data, parent, index);
            }
            else {
                //save index only after add
                var theNode = igtree.nodeByPath(transactions[i].tdata.path[0]);
                deferredIndex[transactions[i].tdata.path[0]] = theNode.parent().children().index(theNode);
                igtree.removeAt(transactions[i].tdata.path[0]);
            }
        }
        $.extend(indexMap, deferredIndex);
    }
}
 

We always want to remove first and then add, this is because the way path is created by primary keys as mentioned. If we add a node with the same path (change in order) and then call remove it will delete both the old and new ones. Also notice the two functions deal with somewhat different issues – the ‘undo’ must clean up additional transactions created by the API methods, while the redo takes advantage the latter in order to have transactions back to the log. Furthermore, processing the ‘addnode’ transaction first means more complications when saving an index, since we need the ‘indexMap’ to still contain the old node’s place when undoing the ‘removenode’, so this calls for saving that index to the side and updating it last. Also to gain initial index we hook up to the node dropping event to save it:

 $(document).delegate("#tree", "igtreenodedropping", function (evt, ui) {
    indexMap[ui.draggable.data('path')] = ui.draggable.parent().children().index(ui.draggable);
});
 

Note that caring for node index in this implementation only has meaning on the client-side, but I think it’s nice to have. Check out below the (slightly large) capture of the Undo/Redo in action – note how the transaction log gets cleared when you undo and the ‘Tofu’ node is back under produce, but the redo stack now holds transactions for it. And as expected it shuffles the two moved nodes afterwards as well:

Resources

As usual the Ignite UI Tree Documentation and jQuery API Reference and detailed samples are at your disposal to draw code and knowledge from!

For the batch updating and undo/redo sample grab the ASP.NET MVC demo project ( with everything from here included in with both MVC helper and script-only demos). Make sure to check that one out! 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 right now on JSFiddle: Ignite UI Tree Drag & Drop + Updating demo.

If this has caught your interest and want to know what other cool tricks you can do with this feature – once more the Tips on Drag & Drop with the Ignite UI Tree await!

Summary

Yet another spin of the in-depth look at the Ignite UI Tree’s Drag and Drop feature. With some insight on the API methods used we were able to use this interaction feature as editing one, by implementing batch updating with the help of the underlying data source. Building on top of that you can actually manipulate the log and use the very same API to add Undo / Redo functionality. And since we change the actual log, transactions going to the server for saving will also be in tune! Again it’s all thanks to the building blocks of the feature and their extensibility!

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

Tips on Drag & Drop with the Ignite UI Tree

[Infragistics] Damyan Petev — 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!

Ignite UI Tree Drag & Drop

[Infragistics] Damyan Petev — Thu, 13 Dec 2012 05:51:00 GMT

With the latest release the Ignite UI Tree has received the nifty feature of drag and drop. It’s a fairly common concept and it allows for a natural (at least I perceive it to be for a long time) interaction with the control’s items. From a user’s stand point it’s all but awesome news - this would allow for nodes to be moved between one tree’s structure and in our case there’s a bonus of being able to do that between two trees even. The feature provides rich interactions with a familiar visual touch out-of-the box.

From a developer’s view things are also quite pleasing – the jQuery Tree Drag and Drop already handles a decent range of common case scenarios, so you can almost set one property and umm.. profit! Then again, when you do need to set things up it offers a possibly familiar API as you’ll see and has pretty much everything conveniently exposed. And while the widget itself will perform a solid range of drop validations it offers you the option to define your additional custom function.

Quick Setup

As advertised, this can be achieved via a single property and you can then kick back and enjoy the result with the defaults. Drag&Drop is build directly into the tree, so no additional files required and main star is the ‘dragAndDrop’ property:

 $('#tree').igTree({
    dragAndDrop: true,
    dataSource: northwindCategories,
    bindings: {
        textKey: 'CategoryName',
        primaryKey: 'CategoryID',
        valueKey: 'CategoryID',
        childDataProperty: 'Products',
        bindings: {
            textKey: 'ProductName',
            valueKey: 'ProductID',
            primaryKey: 'ProductID'
        }
    }
});
 

This setup will pretty much produce a fully functional tree with the bare minimum of setup and the equivalent ASP.NET MVC helper definition is about as simple:

 @(Html.Infragistics().Tree(Model).ID("tree")
    .DragAndDrop(true)
    .Bindings(binding =>
    {
        binding.PrimaryKey("CategoryID")
            .TextKey("CategoryName")
            .ValueKey("CategoryID")
            .ChildDataProperty("Products")
            .Bindings(b1 =>
            {
                b1.TextKey("ProductName")
                .ValueKey("ProductID")
                .PrimaryKey("ProductID");
            });
    }).DataBind().Render())
 

The resulting tree is the one you see in the heading image. Yes, the helpful indicator to the side too! Make sure you stop by the documentation and check out the Enabling Drag-and-Drop section where you can discover that there’s an additional ‘allowDrop’ setting that allows for nodes to be dropped in you igTree from another igTree!

Customizations

Now we come to the part that may be familiar to some of you – the Ignite UI Tree also accepts a ‘Drag and Drop Settings’ object with various settings for the behavior of the feature. Now a small deviation - the reason why the settings might be not so hard to understand is because the control internally implements interactions from jQuery UI – the Draggabe (“Allow elements to be moved using the mouse.”) and Droppable (“Create targets for draggable elements.”) widgets. Taking a look at the descriptions for those you can tell why – just like the concepts of Drag and drop go together, so do those widgets and the tree initializes both itself. Oh and that settings object? Yeah, some settings go almost directly to the Draggabe Widget’s options:

helper – Defines what element (helper) should be used to for dragging display. More on that in the future, lets say you can use the original node or a clone too, just don’t deep clone :) Plus the helper I think will almost always end up being the better UX.
dragOpacity( equivalent to ‘opacity’) – Opacity for the helper while being dragged.
zIndex – This directly corresponds to the CSS z-index Property that will be applied to the dragged element. It specifies the stacking order of elements – making the ones with higher index come on top of those with lower. The default 10 is usually enough, but if for some reason you are having issues with your dragged helper being overlapped by something this is the property to increase.
revert – this one is mildly different as for the Tree it’s a Boolean while the jQuery UI Draggable takes both boolean and two string options. The reasoning behind this is that in the context of drag and drop within the jQuery tree not all of those make sense – like reverting on ‘valid’ drops or always reverting. Plus it makes the option much simpler – false stays the same, while true defaults to ‘invalid’ instead.
revertDuration - The duration of the revert animation, in milliseconds. Ignored if the revert option is false.
dragStartDelay ( equivalent to ‘delay’) - Time in milliseconds after ‘mousedown’ until dragging should start. This option can be used to prevent unwanted drags when clicking on an element. This one is big on user experience I think – trust me when I say you don’t want this too low with complex control with elements that perform additional functions. Based on that the minimum you want is at least 100 milliseconds or you risk drags starting on simple selection and node expansion. It’s pointless overhead and even potentially successful but unintended buy the user moving of nodes.
containment - Constrains dragging to within the bounds of the specified element or region. This one is quite versatile – taking a range of values like a selector, the actual element to contain within, string enumeration or even an array of values defining a bounding box. The default false setting restricts the drag to the parent element of the tree.

Possibly half of the others are left to the default and some the Tree widget reserves for itself. There are of course ways to ‘hack’ into those, but let’s not do that.. at least not just yet. But hey, here’s one that barely counts as one – the cursorAt that defines where the helper markup should appear relative to the mouse cursor regardless of what the name may imply is also defined, however it’s value is set form a constant within the tree and that can be replaced. Keep in mind there’s probably a good reason for that not be exposed, so use with caution – there’s at least one danger - if you go too far and bring the helper under the mouse (which you might decide to do) I guess the validation of the drop target fails and all you’ll be seeing is invalid visual – you need the mouse at least 1px clear from the helper sadly. But hey, you can at least reposition the helper closer and to the bottom right corner (Explorer style) for example:

I’ll admit I didn’t do a particularly good job with that, but hey it’s good to know you can tweak that. If you have been playing with the feature so far you’ll also notice the invalid message is different (it usually shows the name of the node you are dragging) – that’s because you can provide markup for any of the multiple helper states. You can look those up in the Drag-and-Drop Property API Reference where you’ll see the defaults too. Oh right, the code:

 $.ig.loader('igTree', function () {
    $.extend($.ui.igTree.prototype, {
        _const: {
            dragCursorAt: {
                top: -20,
                left: 0
            }
        }
    });
    $('#tree').igTree({
        dragAndDrop: true,
        dragAndDropSettings: {
            dragAndDropMode: 'default',
            dragStartDelay: 100,
            revert: true,
            invalidMoveToMarkup: '<div><p><span></span> <strong> Invalid location. </strong></p></div>',
            containment: "#tree"
        },
        dataSource: northwindCategories,
        bindings: {
            textKey: 'CategoryName',
            primaryKey: 'CategoryID',
            valueKey: 'CategoryID',
            childDataProperty: 'Products',
            bindings: {
                textKey: 'ProductName',
                valueKey: 'ProductID',
                primaryKey: 'ProductID'
            }
        }
    });
});
 

Regarding the various markups – you’ll notice they all contain an empty span. What’s up with that? Well, the span is the one being targeted by the widget to apply classes for the icons. If you want the icon it’s good to include a span in your markup. You can remove it to remove the icon, or leave just the span (with unbreakable space in the paragraph for height) to have a helper with icon only.

Notable mentions from the snippet above also include the mode of the feature ( move and copy available, the default option combines both with a ‘Ctrl’ as modifier. The line at 17 (containment: "#tree") prevents the dragging to go on beyond the boundaries of the tree itself (as in my case with a very simple layout the tree’s parent is the body and that doesn’t always produce good results).

Enhanced Events

The Tree will fire a number of events during the drag and drop interaction. The familiar equivalents of jQuery UI Draggable (start –> drag –> stop) are as follows: ‘dragStart’ –> ‘drag’ –> ‘dragStop’. A slight name change really to better suit the context of a more complex widget. Speaking of which, the control as you can imagine internally handles the original Draggable events to do its work and conveniently fires event for you to handle in the meantime, but that’s not the whole story. While, yes, the Tree will pass you the original Event object, the arguments you get alongside will be extended with a bunch of useful properties containing the path of the node in question, the actual element itself, its data record and appropriate binding. Again you can refer to the API reference or Documentation to get additional info on those. All are cancelable.

Since the Ignite UI Tree also must be the target of the drop, it also has an initialized Droppable widget. However, the events for that are different – the tree will fire events as the node is being dropped and after it has been dropped. As you can imagine the first one can be canceled and is a good place for last checks to see if the node dropping is in an acceptable position. These come from the single ‘drop’ event of the jQuery UI widget, so what happens with the rest? Well, they didn’t make much sense for the Tree, but if you really need to handle some of them for any reason don’t despair – unlike the draggable deeper inside the structure of the control, the Droppable is initialized of the very same element as the igTree and you can handle it’s events just as described in it’s API, for example:

 $("#tree").on("dropactivate", function (event, ui) {
    alert("We have take off!")
});
 

Also you can handle the ‘drop’ as well, but keep in mind you won’t get the extra info the Tree provides in the delegated events and when you do handle drop your handler is likely to be triggered before the Tree’s so you can’t really verify the job is being done there. Just, whatever you do, don’t handle those with alert like I did! :)

Limitations and not so much

I mentioned the control will do a plentiful amount of validation (even without a custom function) in order to maintain reasonable behavior (like the droppable not accepting anything you throw at it an such). The tree will also validate the drop target is an acceptable part of an igTree widget’s UI. in addition to that, as I mentioned before, there is also a binding validation. What this means is that the node being dropped on must have bindings compatible with the dragged node. Take the case above – we have a top tier of Categories whose children are products. Based on that the control will not allow you to drop one Category into another (as the accepted child is defined as Product already). Same goes with trying to drop product in the root (where category is expected). If your models allows identical bindings on all levels then you can ignore that.

This leads to some issues with performing Drag & Drop between two trees as well – you can’t simple define two completely unrelated trees and expect to be able to move nodes between them. Again similar bindings should exist in the trees in order for the move or copy to be accepted. I’m not sure if it’s a limitation if it’s reasonable, but hey you can always work some magic to get around it.

Resources

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

Drag and Drop within a single Tree – you can observe here two interesting behaviors of the control – when checkboxes are enables their state will not be preserved when moving, however when dropped on a parent whose tri-state box is fully checked (meaning every child also is) then the newly added node will follow that rule and also render with ticked checkbox. Also dragging a node over unexpanded one will (after a short timeout) expand the drop target.
Drag and Drop with two Trees – moving nodes between controls with identical binding while avoiding dropping nodes on the ones marked as a file via a custom validation function.
Simple File Manager – Using Drag & Drop to organize files and folders and an additional droppable target you can drop nodes to delete them – all while watching the respective events fly in the log.

Stay tuned! There are some more neat tricks to share about this feature and I plan on another part along with demos!

Summary

We can all agree that Drag and Drop is awesome, simple and intuitive and it’s always great to be able to provide that for your users. As we’ve seen that is as easy as child's play with a mere property or two. However, once you know what you want and the defaults are not it – there’s a plethora of knobs to tweak and some of them.. do they sound familiar? Yes they do, as some come directly from the jQuery UI Dragable and Droppable widgets. Helpers are separated for cases so each can be controlled separately. The control handles much of the work for you by validating proper drop targets on multiple criteria while still providing you with the option to build on that – be it with validation function or by hooking up to one of the elaborate events. Go check out those samples and stay tuned for more!

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

The Future of Story Tests with Selenium WebDrivers and ISTA 2012

[Infragistics] Damyan Petev — Wed, 05 Dec 2012 17:59:00 GMT

This year we had the pleasure of being part of the second “Innovations in Software Test Automation (ISTA 2012)” conference! This year with even more companies joining for knowledge sharing, additional workshop/hands-on track and a lot more participants. ISTA is gathering a healthy range of quality engineers, software test automation experts and developers to the common goal of sharing new technologies and best practices in the fields of automation. This conference provides for a greater exposure of the software test automation role, which makes it a good place for some to choose career path, gain new insight( or share some of their own! ) and generally gain a better understanding of just how diverse problems can be met and solved in the field. Our Principal Architect, Angel Todorov, who’s been recently focused on our Ignite UI jQuery controls gave an awesome presentation on Automated Web UI Testing… on Steroids! More on that later. The goodness spreading doesn’t have to be only once a year, right? Right. So the conference is also issuing a quarterly newsletter (you can sign up here). One of our talented Quality Engineers, Borislav Traikov, has been providing some food for thought via article for the conference newsletter.

The Future of Story Tests with Selenium and WebDrivers

Selenium has been a recurring mention when it comes to Web Test automation – either directly, or a subtle-yet-preferred base for a framework, it comes up one way or another. And frankly I think that’s a good thing, as major companies having interest in the project simply means better support and contribution to it. And I’m definitely not the only one – taken from Borislav’s article:

Performing automated tests on web applications can be crucial to the success of a project, due to the fact that cross-browser support is a mine field for potential problems and defects. On the other hand, web applications are platform-independent (for the most part). Thus, they can be tested natively (with frameworks such as QUnit) in the browser, or by frameworks that utilize first-class languages (such as C#, Java, Python and so on, while this choice provides a wide window for automated testers to step in and start writing tests. So, if a web application testing framework is to be successful, it should satisfy these needs. Selenium has been doing great so far, providing a cross-browser API over multiple languages. While the Selenium API provided great DOM abstraction and traversal, it had its shortcomings – the biggest of which was its use of JavaScript sandboxing (Selenium v.1, also known as Selenium RemoteControl, used the JavaScript engine of the current browser as a way of interacting with it). In most cases that wouldn’t matter, but with more complicated web applications under test, interaction with JavaScript events, rather than emulation of real mouse clicks or keyboard interaction simply wasn’t enough. Also, the Selenium API was growing steadily with each release, and while that was awesome (grey areas were addressed and bug fixes were applied), one had to wait for a release or two to get the API method that they sorely needed (or extend the framework themselves – after all, Selenium is an open-source framework).

While Selenium was rising to fame among automated testers and gathering commercial support, an engineer at Google wanted something more: a test framework that would break free from the JS sandboxing and instead would natively speak to the browser. With so many different browsers, that was no small feat. Thus, the WebDriver project was born. With backing from Google, this automatically meant that Google Chrome (well-known for its distribution of stable nightly builds) and its little brother: the Android browser would be supported. This alone would open the door to a huge improvement in test automation, seeing as how the Android browser holds a solid 24% of the mobile OS market (during the time of writing of this article). However, the other runners-up in this “mobile browser war” – Safari and Opera – are still tough challenges for any cross-browser testing framework.

In 2008, the Selenium and WebDriver teams decided that it was time to join forces and to improve Selenium with the advantages of WebDriver: Selenium WebDriver. The transition from RemoteControl to WebDriver is still going strong alongside the continuous development of the WebDriver API – these facts raise both hopes and questions about the near and far future of test automation with Selenium.

There’s a ton of interesting info in there, pros and cons of the WebDriver and some thoughts on the (hopefully) bright future of test automation. It’s definitely worth checking out, so go ahead and read The Future of Story Tests with Selenium and WebDrivers!

Honorable mentions

That’s not all! There are more topics to spark your interest:

Software Localization … more than just using Google Translate, by Desislava Nikolova

Best Practices: How To Test Performance Of A New Product, by Grigor Svetoslavov

Automated Web UI Testing on Steroids:

Behavior-Driven Development, Headless Browser Environments, and Test Bed Generation.

As I mentioned Angel Todorov presented some of the methods and innovations used right here at Infragistics. Yup, it’s basically info straight from source and it’s pretty interesting stuff as well. The presentation covers a number of limitations, problems and approaches to address them. It starts by giving an overview of some common frameworks and practices used to automate Web UIs, and lists their advantages and disadvantages. It continues by describing a unified framework for UI automation, involving a combination of tools, some of which come from relatively new concepts such as headless browser environments. The key goals? - Faster test execution, more reliable test results, improving code reuse, and achieving greater productivity!

There are details on the cucumber-based framework we are using to describe scenarios and features in the Gherkin syntax and the tools to integrate that into the process. It’s a style that provides readability for the test cases so the stakeholders and managers can take part of the action. Again, something you should definitely not miss – you can follow the link above to read some more and there’s a downloadable version of the presentation deck. For those of you that can’t wait here’s a direct link to slides for the Automated Web UI Testing on Steroids presentation.

I’ll end this with something I’d like to say, but as you see I’ll have to just repeat:

@ISTA_Conference

That was ISTA 2012! You guys rock, thank you! pic.twitter.com/JGnqlToy

And see you next year!

Ignite UI jQuery Mobile layouts and ASP.NET MVC– wrapping it all up

[Infragistics] Damyan Petev — Thu, 08 Nov 2012 18:15:00 GMT

After we’ve looked into the range of input jQuery mobile controls you can use with the greatest ease with Ignite UI ASP.NET MVC wrappers, there is something more you can do. If you try the snippets as is you will find them working well and in tone, but rather lacking in terms of layout. So now that you have an idea how to provide content, let’s wrap it up in some proper containers and provide navigation.

For the record, it’s only fair to say that if you run a sample with just the controls defined you still get the entire page styled. Why is that? Well you can have a look at jQuery Mobile’s “Anatomy of a page”. As it says there the layout consists of conventions, rather than requirements. Wheat this means is that you are not forced to add a header, footer, content or page for that matter. What jQuery Mobile will do is to wrap your entire HTML in the body in a DIV with the page role. That while convenient is not optimal – if you have script tags in the body the process of wrapping the content will also load them again, so it is best advised to still have a properly defined mobile ‘page’ in your HTML. This is also absolutely necessary when two or mode pages are to be delivered in a single file, and yes, that is possible, but again not recommended way of design. So yeah, conventions and not requirements, however those conventions are there for a good reason and you are better off following them. So how about Ignite UI ASP.NET MVC wrappers? Will they help here? Sure!

Mobile pages 101

Let’s start with the most basic thing – the actual page. The helpers will offer a way of defining it that is very similar to how you would go about a Form element. That is in the sense that there are separate methods to begin a page and to end it. However, unlike the form being a set of two methods, the page being Ignite UI means it can also be initialized with a Page Model passed to the view. Here’s how a simple definition with chaining syntax goes ( logically, any options should be in the page opening) :

 @using Infragistics.Web.Mvc.Mobile
 

 @Html.InfragisticsMobile().Page().Title("My App").Theme("b").BeginRender()
<!-- page content goes in here -->
@Html.InfragisticsMobile().Page().EndRender()
 

And as I mentioned this can be done via Page Model:

 PageModel page = new PageModel();
page.Title = "My App";
page.AddBackButton = true;
page.BackButtonText = "Lost? Go back!";
ViewBag.secPage = page;
 

 @Html.InfragisticsMobile().Page(ViewBag.secPage as PageModel).BeginRender()
<!-- ... -->
@Html.InfragisticsMobile().Page().EndRender()
 

How about that back button setting up there? What could that possibly do? Well it’s related to the next otherwise not required layout element – the header. For that setting to have any meaning, you will need a header on your pages as the button will appear just there). There’s another button that you can set text (for tooltip) to but you can’t customize, and that is the close button. Page with close button? Of course, that one is present when the page is opened as a dialog. We’ll talk about how that goes later or, but keep in mind it only makes sense to set one as the close is dialogs’ replacement for the back button.

Headers are used in much the same way as pages (begin and end) and among other things can be set to fixed position:

 @Html.InfragisticsMobile().Page(ViewBag.secPage as PageModel).Url("secondary").BeginRender()
    @Html.InfragisticsMobile().PageHeader().FixedOptions(options => { 
            options.Fixed(true).TapToggle(true).Transition("slide"); 
    }).BeginRender()
        <h1> Second page</h1>
    @Html.InfragisticsMobile().PageHeader().EndRender()
    <!-- ... -->
@Html.InfragisticsMobile().Page().EndRender()
 

The ‘FixedOptions’ can also set behaviors like tap (or click) to show/hide the fixed header and transition animation for showing (the default is slide). There’s more of course and you can pay our Ignite UI Mobile Documentation a visit. The And you will see something similar to this in the light WP theme:

Linking

One thing still is escaping – how did the user get here? Well he followed a link of course. jQuery mobile provides some enhancements to those as well. Links can be in three styling modes – the native for the browser, the link styling of the theme or as a button. Note that links inside headers and footers will always be styled as buttons whether you set them to or not. Also I mentioned dialog and you can tell the framework to load something as dialog when you specify an option on the link itself:

 @Html.InfragisticsMobile().Link().NavigateUrl("#secondary").RenderMode(LinkRenderMode.Button).Text("secondary page").Render()
@Html.InfragisticsMobile().Link().NavigateUrl("#dialog").DestinationRelationship(LinkDestinationRelationshipOptions.Dialog).Text("dialog page").Render()
 

The above will produce:

As you can see you have the option to define a relation with the destination or the link, and this is how you create interactions to open up dialogs and popups. This is a similar page opened up by the dialog link above:

You can also specify relation to be ‘back’ so you can add back buttons not just in headers but anywhere in your content. Keep in mind automatic Back button on on pages only appears if there's actual history – as in when they have been navigated to by a link. This is somewhat important to know when using multiple pages in a single document (even thought it’s not a recommended practice) as you can force loading secondary pages by entering their URL but this way jQuery Mobile won’t add those to the history. Still, there’s a very minor chance someone will be entering links by hand, but you never know. Also for back buttons it’s good to still provide a meaningful link for browser compatibility.

More?

So far you can create basic pages and provide navigation. Also at your disposal is the content element – as the documentation describes it is helpful for “providing some basic formatting and structure”. But, hey, have you noticed the simulator screenshot in the previous blog? Does it seem odd items are stretched so far out it feels they are about to be cut off by the viewport edges? That’s because as direct page content they tend to spread to the maximum width… Wrapping those in a content element is at least the easiest way to provide proper formatting as the content will squeeze them a little. Also you can set separate theme to he content this way or apply classes to add custom styling and behavior with.

The same statement that describes the content is also true for the footer. But while it is not required for automatic page functionality like back/close buttons and it also serves the structural and potentially visual separation of content, it can much like the header be fixed, which can sometimes be really useful. So for that secondary page we have above we can add something like the following:

 @Html.InfragisticsMobile().PageContent().BeginRender()
    There's some content in here. x 50
@Html.InfragisticsMobile().PageContent().EndRender()
 
@Html.InfragisticsMobile().PageFooter().BeginRender()
    <p> (c) My Company </p>
@Html.InfragisticsMobile().PageFooter().EndRender()
 

Enhanced Layout

Now that you can properly fill those pages comes yet another potential problem. While you have been refactoring your site’s experience into mobile pages to be properly consumed on mobile devices it still is too hard to fit relevant content together into a single page? Well you don’t have to, really.

You can separate content that is not for immediate consumption or instead of swapping pages on some event show content in a popup. It’s extremely useful for a range of cases – from simple tooltip to login forms and application menus. Keep in mind the popup is available from 1.2.0 version of jQuery Mobile! Like other content containers, the popup has begin and end methods and content between them is not displayed by default. To display a popup you can set up a link (on the same page) that navigates to the popup ID and has a relation of that type and inside you can add another link as close button:

 @Html.InfragisticsMobile().Link().NavigateUrl("#DownloadPopup").DestinationRelationship(LinkDestinationRelationshipOptions.Popup).Text("Click here!").Render()
 @Html.InfragisticsMobile().Popup().ID("DownloadPopup").History(false).PositionTo("window").Tolerance(10).Transition("pop").BeginRender()
     @(Html.InfragisticsMobile().Link().NavigateUrl("#").DestinationRelationship(LinkDestinationRelationshipOptions.Back).RenderMode(LinkRenderMode.Button)
             .Icon(DefaultIcons.Delete).IconPosition(IconPositions.NoText)
             .HtmlAttributes(new Dictionary<string, object>() { {"class", "ui-btn-right"} }).Render())
     <a title="Donwload your Ignite UI Free Trial now!" href="http://www.infragistics.com/products/jquery/downloads" target="_blank">
         <img src="@Url.Content("~/Content/IgniteUI-download.jpg")" alt="Download Ingine UI" />
     </a>
 @Html.InfragisticsMobile().Popup().EndRender()
 

The button class can be left and right and the contents of the popup can be any HTML. As seen options include positional settings like centering over the element that was clicked (origin) or the window. You can even pass a jQuery selector to position the popup over the matched element. And the tolerance sets up how much in the minimum spacing between the popup and the edge of the window. The MVC wrapper method has 3 overloads that let you put a single common value, just for top and left or for all sides. The transition has the usual jQuery animations available and another allows (or not) for jQuery Mobile to modify the page Url and add it to the history. This means you can let your users to close popups with the back button.

Another extremely useful layout trick is to organize things within collapsible container. They come in two varieties – a standalone Collapsible and a Collapsible Set. While pretty self-explanatory the single version consists of a header and a content block that is either visible or collapsed. You have a number of options to control themes, header state icons and their position and more. For example the default icons are plus and minus, while we can use arrows instead:

 @(Html.InfragisticsMobile().Collapsible().HeaderText("radio button groups").ContentTheme("c")
        .ExpandedIcon(DefaultIcons.UpArrow).CollapsedIcon(DefaultIcons.DownArrow).BeginRender())
        <!-- ... -->
@Html.InfragisticsMobile().Collapsible().EndRender()
 

The set version is essentially an accordion – only one out of a group of blocks can be expanded at a time and current collapses automatically when the user opens another. The model is pretty much identical – you have the set that is a container for single collapsibles and it even has the same general options (icons, themes) that you can apply for all child blocks:

 @Html.InfragisticsMobile().CollapsibleSet().ContentTheme("c").BeginRender()
<!-- standalone collapsibles here -->
@Html.InfragisticsMobile().CollapsibleSet().EndRender()
 

Of course, it’s always nice when you can make the web page feel more like an application and provide nice buttons instead of links. It’s also nice if those are not spread all over the page, but rather grouped. Here is where the Navigation bar comes in play – it allows you provide up to 5 (after which it wraps them in multiline..) buttons with customizable themes, icons and exclusive selection (kinda like horizontal radio group but without the form input support). This toolbar is most common in headers or footers. The control itself has a collection of items, global icon positioning an theme options. Each item has Url and text as expected:

 @Html.InfragisticsMobile().NavBar().IconPosition(IconPositions.Top).Items( item => 
    {
        item.NavBarItem().NavigateUrl("#secondary").Text("secondary page").Icon(DefaultIcons.RightArrow);
        item.NavBarItem().NavigateUrl("#dialog").Text("dialog page").Icon(DefaultIcons.Info);
        item.NavBarItem().NavigateUrl(Url.Action("Index", "Type")).Icon(DefaultIcons.Gear).Text("Strongly-typed");
    }).Render()
 

TL;DR | Summary

In this article we’ve looked into the basic ways to create structure in your mobile applications using the Ignite UI ASP.NET MVC wrappers/helpers. In addition, we saw how linking between pages can be done with different relations and styles. Furthermore, there were the mode advanced ways to enhance experience with your app by providing interactive content with popups and collapsible content. Lastly, a more neatly organized way to build your navigation in a toolbar that also provides a nice touch of ‘native’ feel to the mobile app.

Make sure you stop by the first part for some input jQuery mobile controls you can use with the greatest ease with Ignite UI ASP.NET MVC wrappers, check out our Ignite UI Mobile Documentation and visit our samples you can experience on your mobile device as well! I have packed all of the described examples in a very simple ASP.NET MVC solution for you to download and try and in order to run that you will need at least a Trial version of Ignite UI for the mobile assembly, but hey it’s free, grab one from here:

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

Reach further with IgniteUI jQuery Mobile controls and ASP.NET MVC

[Infragistics] Damyan Petev — Mon, 05 Nov 2012 22:54:00 GMT

Out of the new and exciting things happening around IgniteUI is the enhancement of the mobile toolset. These controls are based on jQuery Mobile rather than jQuery UI, as it provides optimizations for mobile devices. Applications built using them meet the demands of phones and tablets when it comes to usability and design. Windows (Phone) 8, iOS and Android devices are everywhere and the flavor of the year word is TOUCH - support for that and responsive design both come out-of-the-box. But this isn’t the first time we’re taking on the subject – some time ago (in 12.1) we released the mobile ListView and Rating where some parts were covered. Even though for now I’ll keep to the present and show you some of the new stuff, leave a comment if you have some thoughts on anything else. Also make sure to check out the topmost link for a list of all IgniteUI changes.

So, possibly the biggest change introduced with 12.2 now is for all of you ASP.NET MVC lovers :) We’ve devoted effort to enrich the mobile toolset by adding 17 ‘new’ controls by providing what we call “re-assurance” wrappers around existing jQuery Mobile controls. What this means is that you get not only Infragistics support for them, but hey, as part of our suite you can bet on each of them having a model for neat ASP.NET MVC Helper action! Yup – means you can code jQuery Mobile based applications with Razor syntax in C# or VB.NET! Also you get enhancements such as the control model themselves so they can be configured outside the View as well for maximum control and when in the View – the option to create strongly-typed controls!

What are the goodies?

With the latest additions the IgniteUI package is capable of delivering an application in its entirety all in the comfort of the IDE and language you feel accustomed with. But it’s not just the controls that grew in numbers – to truly provide a full-fledged end-user experiences we also added themes for Android (whole 3 of them) and two for Windows Phone! And there’s even support for adaptive theming to match the device platform feel! I’ll try to demonstrate different themes along the way and you can always hit up our samples and see for yourself!

There are also a number of benefits you get – the mobile jQuery controls now have their own section in the IgniteUI Documentation/Online Help with very useful mobile-centric Deployment guide and detailed control documentation. You should totally check that one out as well.

In addition to what I mentioned above ( the comfort of your IDE and language, strongly-typed) the MVC wrappers bring quite a bit more – having server model of your client controls lets you define them without requiring the knowledge of their HTML structure and with IntelliSense support.

They will also prefill defaults for you, the ones that matter the most – required for the control to be initialized, automatic element IDs and in the case of strongly-typed controls like above the proper model property will be set as both ‘id’ and ‘name’ attribute of the elements in order to be properly picked up and sent upon form submits.

In case you think typed models of controls will take away the freedom you can have with just HTML, you can rest assured that is not the case as all the models accept extra settings via the HtmlAttributes method.

Getting started with mobile controls

Let’s see just how easy it is to create basic mobile applications. Make sure you have followed the Deployment guide above and referenced the jQuery mobile recourses and IgniteUI ones or the mobile version of the loader widget.

The most basic control you could use is the TextBox that supports different modes such as password, multiline and search.

 @Html.InfragisticsMobile().TextBox().Mode(TextEditorTextMode.Search).Render()
 

And this in the Android “Holo Light-Dark” theme comes out as:

Then you can have Buttons of course! Notable properties of the buttons are the icons (with related positioning properties) along with the ability to define them as inline (otherwise to ensure fit for small screens jQuery Mobile elements are usually displayed in block, as in a new line):

 @Html.InfragisticsMobile().Button().HtmlAttributes(new Dictionary<string, object> { { "class", "pop" } }).Text("button").Mini(true).Icon("gear").Render()
@Html.InfragisticsMobile().Button().IsSubmitButton(true).Text("submit").Inline(true).Render()
@Html.InfragisticsMobile().Button().Text("cancel").Inline(true).Render()
<style>
.pop 
{
    text-decoration: none;
    line-height: 1.5em;
    background-color: #ACACAC;
    color: #fff;
    border: none;
}
 
.pop:hover
{
     background-color: #007FAF;
}
.pop:active
{
     background-color: #00AEEF;
}
</style>
 

I’ve also added the style in here so you can see that you can even make use of the html attributes to add class and apply custom styling:

That doesn’t really fit, but oh well :)

Next up is the Slider so let’s see how you can set it up on the server using the model:

 using Infragistics.Web.Mvc.Mobile;
 

 SliderModel slider = new SliderModel();
slider.NumericInputDisplayMode = DisplayMode.Inline;
slider.MinValue = 0;
slider.MaxValue = 100;
slider.Value = 30;
slider.Label = "Progress:";
slider.LabelAlignment = Alignment.Top;
ViewBag.Slider = slider;
 

You can pass the model itself if you will, but I’m actually using the dynamic ViewBag because I have more then one model for that view. The Helper as always comes with an overload taking a ready control model:

 @Html.InfragisticsMobile().Slider(ViewBag.Slider as SliderModel)
 

Moving on with the all-time favorite Toggle switch. It’s one of those mobile specific controls that is very easily recognized. The two states of the control are called on and off and you can specify text for both, as well as initial state. With all controls you can also apply themes (or swatches as they are defined within the jQuery Mobile styling):

 @( Html.InfragisticsMobile().ToggleSwitch().Render()
)
@( Html.InfragisticsMobile().ToggleSwitch().ID("test2").OffText("disabled").OnText("enabled")
        .SwitchedState(true).Width("10em").Theme("b").Render()
)
 

Those are the Android-styled toggles.

Another very mobile-oriented control would be the Select Menu – very much behaving like a select but with enhanced popup-like modal selection for better mobile experience. Much like other selects and combo boxes, it supports both single and multiple selection, the option to use native menus ( don’t know why would you punish users like that, but it’s there) and a collection of items:

 @Html.InfragisticsMobile().SelectMenu().Multiple(true).Label("Favorite language:").NativeMenu(false).Items(s =>
    {
        s.MenuItems.Add(new SelectMenuItem { Text = "JavaScript", Selected = true});
        s.MenuItems.Add(new SelectMenuItem {  Text = "C#", Value = "CSharp" });
        s.MenuItems.Add(new SelectMenuItem { Text = "TypeScript"});
        s.MenuItems.Add(new SelectMenuItem {  Text = "VB.NET" });
    }).Render()
 

The interesting part is that it would also display a counter if multiple are selected(if you want it to naturally – as with most it is customizable):

Speaking of selection there are two more well-known user-selection that the above menu is really based on. First are the Checkbox and Checkbox Group – fairly simple two-state input element, that when used in group allows for multiple selection. The checkbox can be used as stand-alone as expected or as part of the group model’s collection of items:

 CheckBoxGroupModel cbgrp = new CheckBoxGroupModel();
cbgrp.ID = "chkBoxGrp";
cbgrp.Items.Add(new CheckBoxModel() { Checked = true, ID = "opt1", Text = "Option1"});
cbgrp.Items.Add(new CheckBoxModel() { ID = "opt2", Text = "Option2"});
cbgrp.Items.Add(new CheckBoxModel() { ID = "opt3", Text = "Option3"});
ViewBag.ChbxGrp = cbgrp;
 

 @Html.InfragisticsMobile().CheckBoxGroup(ViewBag.ChbxGrp as CheckBoxGroupModel)
 

And if you set the ‘Horizontal’ property to true you get a single line button or also called toggle set:

The other selection option in the toolset is the Radio Button Group – with the difference that radio buttons make no sense outside of a group and when grouped only a single one can be selected. Again as you’ve seen above you can set initial selection, but the group model itself can be assigned a ‘SelectionIndex’ (but keep in mind it is overridden by selection assigned on the radio elements themselves). Also, much like above the the group can be set up as horizontal button set:

 @(
 Html.InfragisticsMobile()
    .RadioButtonGroup()
    .ID("ageRange")
    .SelectedIndex(1)
    .Items(item =>
    {
        item.RadioButton().ID("grp1").Text("18-25");
        item.RadioButton().ID("grp2").Text("26-35");
        item.RadioButton().ID("grp3").Text("36-45");
        item.RadioButton().ID("grp4").Text("45+");
    })
    .Render()
)
 

As form elements

Since in this article the main focus is on input elements, I feel it’s important to explain a bit how they work in the context of HTML forms. Usually you will be working with all familiar elements, however as mentioned above some controls provide the ability to use native ones – what does it mean? Well, even though there are probably default UI elements available, in jQuery mobile standard elements are primarily built out of spans. This ensures no browser enforces its own default UI or behavior and therefore cross-browser compatibility. This applies to things such as buttons, checkboxes, radio elements and so on. However, in the interest of remaining with a functional application when jQuery mobile is not supported (simple HTML mode, no JavaScript - although I have no idea where you'd find that except for those that turn it off on purpose), buttons (and other inputs) intended to perform the default browser submit functionality will be created as styled standard input of type submit.

Also a very important part is that the IgniteUI ASP.NET MVC wrappers will create the proper markup (such as intended to be used with jQuery mobile) that would create native browser elements and assign them the proper ‘id’ or ‘name’. Those contain the actual values and are the ones picked by the browser on submits. However, when jQuery mobile is functional they will remain hidden, while the user interacts with the enhanced mobile controls. That also means in case something goes wrong the application will have this whole set of active controls and will perform as expected, but with reduced usability. Again this is something you won’t have to worry about, but it’s good to know.

TL;DR | Summary

We’ve looked into mobile controls that assist with user input and help you create immersive mobile experiences that implement cross-browser and cross-platform responsive design and go beyond – while optimized for touch and mobile, jQuery mobile applications actually look and work beautifully on desktop browsers! There’s a very extensive list of supported platforms and let’s just say the A-grade list is impressive.

But there’s more – the IgniteUI mobile toolset will also provide you with a number of wrappers around layout elements to help you build your application that much easier in a familiar way and environment. So stay tuned for the upcoming blog demonstrating those, demos and more! In the meantime you can always try it for yourself:

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

Get JavaScript code generated for you with the IgniteUI control configurator

[Infragistics] Damyan Petev — Tue, 30 Oct 2012 20:33:00 GMT

Not so long ago when Jason announced IgniteUI and a plethora of other goodness he mentioned a tool called Configurator that would help you code (or not code really) widgets included in the suite. As as he put it, for all of you server-side developers with desire to fire up your pages with some HTML5 and jQuery that sounds fantastic!

“Configurator for IgniteUI jQuery widgets? Where? Why is it not in my install folder/IDE?”

So yeah, there’s that. It’s not something you’d find in the installation of IgniteUI. It’s a live tool actually and there’s actually a link for that in the post in case you missed it.

You could always follow the direct link to the Configurator which is http://labs.infragistics.com/jquery/configure/, but it’s not all too confortable and far from enough don’t you think? Well we agree and we are moving forward with the Configurator making it easily accessible from the IgniteUI home page:

There you go, now you know where you can find it when you feel like some fiddling.

Note: This is in a early stage (hence the big ‘BETA’ stamp on it). While we welcome you to give it a try, you shouldn’t expect correct behavior in all cases.

The Goal

Speaking of fiddling the experience does remind me a bit of a reverse JFiddle – where you start from the results you want to see and get the code as a result. And that’s exactly what this tool is all about - it’s all “Developers, developers, developers!” deal with this one. And if you are like me and you love to learn by example and in our line of work that is by code. Then getting a ‘default settings’ code with very little knowledge of the IgniteUI controls – sure we want that. Also improve the learning curve of the controls? Why yes please! Experienced developers could instead use it instead to grab a quick piece of code to begin molding to their needs? Sure! There are a whole bunch of ideas behind such a tool that are just awesome. And you can say that yes we have samples (which I might add are quite awesome!) but they can’t cover all the events a control has as it would just not make sense in a real case. Also there are sometimes more properties that can be stuffed in there as well. And yes we do have rich API reference that lists all options and events, but hey what if you could see what they do instantly? What if the demo-ing control could also be modeled to your specification and data model? Well that’s the goal! To let you access and customize controls in a familiar fashion and with boosted speed and ease.

The Configuration ‘studio’

It’s kind of weird to have a getting started guide for a tool that is partly here to help with get star.. you get the point! Well ‘Introduction’ then. Firstly, you don’t really need to worry about resources and stuff, just follow the link and tweak/fiddle! Once there you will see the ‘studio’ has three main areas – toolbox with IgniteUI controls, live workspace and Visual Studio style properties and events tabs ( nice touch with familiar experience there):

Furthermore, on the matter of properties – the configurator is aware what are the default options for the controls so when met they will be omitted to produce clearer code. Let me give an example – as with the editor above you can set the vote count to 6 or 7 and that will reflect in the code, however when you enter back 5 the property won’t be in the source anymore as that is the default option to begin with. And once you are happy with the result you can hit “Source” and grab the corresponding code:

Note: While the code field is editable as I said this is like a reverse fiddle – the source is generated from the design rather than the other way around and changes made in code will just be lost once you switch to design. This is somewhat of a limitation regarding events as you can see – you get a handler function prepared for you, but since the tool can’t anticipate what it should do it is empty.

So we heard you like Grids…

So while the Configurator has a lot of catching up to do, but there has been a special focus on our powerful and feature rich jQuery Grids! And by feature rich in this case read “a plethora of settings to customize each” – I don’t even know if there is a golden middle between ease of use and freedom for the developer, I guess IgniteUI grid features being separate widgets helps some, but it does sometimes make it hard to find what you are looking for. For that reason the grids are sometimes difficult to configure and this is where this tool shines. Currently it does have some quirks still so I’ll attempt to guide you. Once you have picked a control you get it in a ‘sample’ version with some dummy data..that unfortunately isn’t being pre-populated in the options to the side. So if you want to get some customizations rolling, first make sure you have your data set. Simple walkthrough with a grid:

Start by setting the data source type and response key (if any, as with lack of scheme it is used to parse the data) before you paste actual data because for now the workspace is not equipped with a reset button and the grid will error out attempting to parse the data:

Also for advanced features it’s best to also set the primary key. After that you can paste your data in the data source field. Here’s mine and you can reuse or just provide your own:

 {
    "Records" : [{
            "BusinessEntityID" : 2,
            "SickLeaveHours" : 20,
            "VacationHours" : 1,
            "test" : 1
        }, {
            "BusinessEntityID" : 3,
            "SickLeaveHours" : 21,
            "VacationHours" : 2,
            "test" : 2
        }, {
            "BusinessEntityID" : 5,
            "SickLeaveHours" : 22,
            "VacationHours" : 5,
            "test" : 3
        }, {
            "BusinessEntityID" : 6,
            "SickLeaveHours" : 23,
            "VacationHours" : 6,
            "test" : 4
        }, {
            "BusinessEntityID" : 14,
            "SickLeaveHours" : 21,
            "VacationHours" : 3,
            "test" : 5
        }, {
            "BusinessEntityID" : 15,
            "SickLeaveHours" : 22,
            "VacationHours" : 4,
            "test" : 6
        }
    ]
}
 

The grid is auto-generating columns by default and once the source field loses focus the grid should appear.

Tweak options. Keep in mind field blurs cause the demo grid to reload with the new settings and produce errors if vital ones are missing/incorrect. Also enable and configure grid features! In the properties tab there’s a features option with an edit button that takes you to a view with all available features that can be enabled:

And as you can see each feature has its own ‘Edit’ button that takes you the respective feature widget options where you can toggle and set even more options and at any point you can hit the source and grab the generated code.

Note: What I explained for the grid with dummy data and the need to provide your own is true for all data bound controls at the moment. So, for example, a Pie Chart would require you to set data type, along with Value and Label member paths and paste something like the following JSON:

[{"Budget":60,"Label":"Administration"},{"Budget":40,"Label":"Sales"},{"Budget":60,"Label":"Finance"}]

This is the actual pie chart dummy data by the way :)

Just for now

For those experienced with web development the developer tools console of your favorite browser should feel like natural habitat. For those not so much experienced, well lets say that is while you are making changes something goes wrong for now the way to get at least some in for is by looking at the console. Also while at it you can use it to define global variables and functions to use with the controls – there are no iframe-s going on in the Configurator so you won’t to worry if those will be available.

Looking ahead

It seems this is quite often the case – the simpler a tool is supposed to make your like, the harder it would be for someone else to create it. It’s really a lot of work to make this perform flawlessly and then even more so to pack it up with amazing features. So as I mentioned before it is in beta stage and right now is the ideal moment for your voice to be heard.

For the future of the tool we’d like to let you add multiple controls to the workspace and also provide generation for ASP.NET MVC code. There are also a number of functionality enhancements and fixes and until then if you get stuck.. refresh away :)

We would appreciate feedback on what you think about the tool, what would like to see in the future and how would you like to use such a tool.

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

[Infragistics] Damyan Petev — 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.

Damyan Petev's Blog

Responsive Web Design with jQuery Grids: A closer look

A Getting Started, of sorts

Merging and Column Hiding

Responsive Hierarchical Grid

Resources

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

jQuery Grids with Multi-Column Headers

Quick Start

Not so fast!

Feature interaction

Resources

Grid Multi-Column Headers sample

Hierarchical Grid Multi-Column Headers sample

Ignite UI jQuery Grid Column Moving

Getting started

Notes, tips and tricks

Making use of events to enhance functionality

Resources

Financial charting with Ignite UI

Get to know the Financial Price Series

The technical stuff

Resources

PHP Server-side wrapper for the Ignite UI File Upload

Limitations, limitations and then some..

Workarounds, hacks, tricks, etc.

Usage

The future looks HTML5 bright…

Using jQuery UI Controls with WordPress

General

What are your options?

Shortcodes

Widgets

Plugins

What do you think?

How to add updating to the Ignite UI Tree’s Drag & Drop

Leaving a trace behind

Go there! No, come back! Actually…

Resources

Summary

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

Ignite UI Tree Drag & Drop

Quick Setup

Customizations

Enhanced Events

Limitations and not so much

Resources

Simple File Manager – Using Drag & Drop to organize files and folders and an additional droppable target you can drop nodes to delete them – all while watching the respective events fly in the log.

Summary

The Future of Story Tests with Selenium WebDrivers and ISTA 2012

The Future of Story Tests with Selenium and WebDrivers

Honorable mentions

Automated Web UI Testing on Steroids:

Ignite UI jQuery Mobile layouts and ASP.NET MVC– wrapping it all up

Mobile pages 101

Linking

Enhanced Layout

A nicely packed navigation

TL;DR | Summary

Reach further with IgniteUI jQuery Mobile controls and ASP.NET MVC

What are the goodies?

Getting started with mobile controls

As form elements

TL;DR | Summary

Get JavaScript code generated for you with the IgniteUI control configurator

The Goal

The Configuration ‘studio’

So we heard you like Grids…

Just for now

<script>

function customValidation(element) {

// omitted

}

</script>