Search results matching tags 'Cross-Platform' and 'Hierarchical'

jQuery Grid Checkbox Column alternatives (continue)

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

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

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

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

The Checkbox column feature to the rescue!

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

The template

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

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

Now the structure for the spans:

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

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

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

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

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

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

One-click inline value updates

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

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

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

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

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

Editing Action

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

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

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

Editor provider

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

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

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

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

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

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

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

Comparison

PROS

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

CONS

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

Conclusions

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

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

jQuery Mobile Controls by Infragistics

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

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

Enter the Infragistics jQuery Mobile controls

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

The List view

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

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

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

The Rating

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

Style

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

A Mobile App

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

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

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

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

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

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

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

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

Wrapping Up

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

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

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

Merging Cells with the Infragistics jQuery Grids

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

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

Merging Cells

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

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

Steps

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

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

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

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

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

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

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

Further enhancements

Multiple column sorting and merging

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

Hierarchy

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

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

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

Events

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

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

Wrapping Up

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

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

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

Using Sparkline Chart Columns in XamGrid

dpetev — Thu, 26 Apr 2012 09:12:00 GMT

Not that long ago I demonstrated how you can integrate our Sparkline control inside the cross-platform XamGrid. Well it seems like that might be a thing of the past now – no, not the Sparkline integration, but the method itself. While it would still be possible to go that way, a new feature coming in 12.1 would be a dedicated Sparkline Column type available for the XamGrid! The Sparkline control is still the same compact, yet fully-functional chart that can provide valuable information at a glance right on the spot – inside the grid, next to your data. If you need a reminder of what kind of control this is - here’s how the end result from what’s will be shown below can look :

The improvement is that with the new column type, adding this ‘compressed’ chart has never been easier, so let’s see just how that goes!

Preparations

Now there are a few interesting changes with the XAML products as a whole – like the Silverlight assemblies being build against Silverlight 5 and the now combined packages for platforms( or soon to be anyway). So when you are referencing assemblies this time it won’t be the Silverlight base along with the Silverlight Data Visualization for the chart. The assemblies to add for this demo include:

InfragisticsSL5.v12.1
InfragisticsSL5.Controls.Grids.XamGrid.v12.1
InfragisticsSL5.Controls.Grids.SparklineColumn.v12.1
InfragisticsSL5.Controls.Charts.XamSparkline.v12.1

Or the equivalent for WPF (they have identical naming starting with InfragisticsWPF4 instead).

Data

The data source for this demo would be (you guessed it!) Northwind, of course. It’s Entity framework model looks like so in the designer:

Based on that model we will be using the Orders collection for each Customer as the data source for our Sparkline charts. The data context of the grid will be set to the resulting collection of Customers on the ‘Loaded’ event of the layout root container. Possibly one cool aspect of this control is that by using it you can ‘flatten’ (figuratively speaking) the UI for your hierarchical data by focusing on one of it’s significant properties – in our case if we are only interested in keeping an eye on the freight values for each customer’s set of orders, we can do that by displaying them in a Sparkline, rather than adding a child layout for just that one field.

The XAML

Of course, you can set up columns based on that, but just for the sake of getting this done very easily and fast we would let the XamGrid figure out the columns itself and only define the one we are interested in:

<ig:XamGrid x:Name="xamGrid" AutoGenerateColumns="True" ItemsSource="{Binding}" >
    <ig:XamGrid.PagerSettings>
        <ig:PagerSettings AllowPaging="Bottom"></ig:PagerSettings>
    </ig:XamGrid.PagerSettings>
    <ig:XamGrid.Columns>
        <ig:SparklineColumn 
            Key="Orders" 
            LabelMemberPath="OrderID"
            ValueMemberPath="Freight" 
            DisplayType="Line"                     
            >
        </ig:SparklineColumn>
    </ig:XamGrid.Columns>
</ig:XamGrid>

As this method adds Sparkline Charts using this new column and not the actual control itself it shouldn’t be a surprise the column itself exposes a plethora of column-specific setting and only the very essential ones for the XamSparkline. If you want to tweak the charts further – don’t worry, that is not ruled out. Simply create a style targeting the XamSparkline and and you can set all the properties you want – from default element ones like height or margins, show parts of the chart like axes, markers, normal range and trend line and styles for those and so on… Here’s one just a tiny bit overdone snippet with such a style:

<Style TargetType="ig:XamSparkline">
    <Setter Property="Height" Value="90"/>
    <Setter Property="Width" Value="190"/>
    <Setter Property="ToolTipVisibility" Value="Visible" />
    <Setter Property="VerticalAxisVisibility" Value="Visible" />
    <Setter Property="HorizontalAxisVisibility" Value="Visible" />
    <Setter Property="HighMarkerVisibility" Value="Visible" />
    <Setter Property="LowMarkerVisibility" Value="Visible" />
    <Setter Property="HighMarkerSize" Value="3" />
    <Setter Property="LowMarkerSize" Value="3" />
    <Setter Property="NormalRangeVisibility" Value="Visible" />
    <Setter Property="NormalRangeMinimum" Value="0" />
    <Setter Property="NormalRangeMaximum" Value="50" />
    <Setter Property="TrendLineType" Value="ExponentialAverage"/>
    <Setter Property="TrendLineThickness" Value="2" />
</Style>

Of course that style enables a whole bunch of extra features that appear on the UI and depending on your needs/taste you might only use some of them.

Conclusion

The very same data-intensive chart with the potential to really help you spot trends in your data right inside the grid. Plenty of ways to display your data and really make the important bits of it ‘pop’ – normal range, Win-Loss type chart type, minimum and maximum markers and normal range. Here's how the very same application can so dramatically change looks just by changing the sparkline type to column:

(Really manages to be the center of attention right? )

This awesome functionality now integrates seamlessly in the XamGrid via this new column type and provides for very rapid implementation of such features in your application.

The new release is very close, so soon a demo shall grace this blog along with the others :)

Column Templates for the jQuery Grids

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

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

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

Just a few steps

Adding in scripts

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

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

would result in loading those files:

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

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

Template strings

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Setting up the grid

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

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

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

Conclusion

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

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

What is Continuous Virtualization in the jQuery Grids?

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

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

Virtual you say?

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

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

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

Filling the gaps

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

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

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

-First and foremost – enable virtualization

- Set the virtualization mode to continuous

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

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

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

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

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

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

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

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

With even more hierarchy

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

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

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

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

The advantage you get

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

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

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

Sparkline integrated in WPF Data Grid

dpetev — Wed, 22 Feb 2012 08:02:00 GMT

This post is kind of a follow up, part two if you will, on integrating the XamSparkline – a XAML cross-platform control part of both NetAdvantage for WPF and Silverlight Data Visualization packages – into Infragistics grids’ cells.

If this is your first meeting with this neatly fitting, data-intensive control - make sure you start with Atanas Dyulgerov’s Introduction to the Infragistics Sparkline Control blog post. And if you missed my first post, you can click to read about integrating the Sparkline in a XamGrid.

With that said, you should be aware it’s no pain to incorporate the XamSparkline in a XamGrid which made for a quite easy implementation with code that is even easier to transfer between platforms. And even so, this is far from enough. We now turn attention to those who went “But we already have a huge project with the XamDataGrid instead!” or “We just like the other grid better, have you forgotten about it?”. And we hear you – as it will now be demonstrated it’s not much of an issue to use the Sparkline in the WPF-Only data grid, too.

Seeing as this is the second blog post on that subject I would like to remind of our little scenario – the goal is display hierarchical data, but in the same time provide extremely important information from the child records in the parent row for very quick reference and to do that we settled on using visual representation (the XamSparkline) to provide the users with the ability to instantly spot odd values or trends. And again there is a teaser screenshot:

This time we would provide freight expenses for each customer with the idea that the user should be able to see any too sudden changes in their orders.

Preparations

Once more - no difference when it comes to the products – a combination of NetAdvantage for WPF Line of Business and Data Visualization, which essentially means you will need at least trial versions of both.

In terms of data, as the finer points of the XamDataGrid and not the focus of this post, we can again rely of the Help Topics to provide fast-starter solution with the SampleDataUtil class. You can pick between C# and VB.NET implementations of this class and it will give you easy data access, only assuming you have the Northwind sample database. Should a different method be required or just better suits your taste, you can always find information on Accessing Data using the XamDataGrid Help Topics.

As always a list of assemblies and namespaces to be added to your project. In you XAML add the following namespaces:

  xmlns:ig="http://schemas.infragistics.com/xaml"  
 xmlns:igDP="http://infragistics.com/DataPresenter"
 

First one is where all the shared XAML controls from Infragistics are (including the XamSparkline) and the second one as it’s name suggests – is for the XamDataGrid, which is a part of the xamDataPresenter™ control family.

Then come the assemblies to reference - starting with the base InfragisticsWPF4.v11.2.dll, then InfragisticsWPF4.Editors.v11.2.dll and InfragisticsWPF4.DataPresenter.v11.2.dll required by the data Grid and finally the InfragisticsWPF4.Controls.Charts.XamSparkline.v11.2.dll for the sparkline itself.

When that is done you are ready to add a XamDataGrid to your XAML and also add a handle for the Windows’s Loaded event while at it:

 <Window Loaded="Window_Loaded"
        <!--...-->
 

 <igDP:XamDataGrid x:Name="XamDataGrid" InitializeRecord="XamDataGrid_InitializeRecord">
     <!--To do: Add Field Layout-->
 </igDP:XamDataGrid>
 

Now in the code behind once the Window is loaded we will provide data to the grid using the functionality provided for us by the data access class mentioned earlier. Since I have Northwind on my SQLExpress instance, the parameter to pass would be set to that with the standard “.\” which is the equivalent of localhost:

 private void Window_Loaded(object sender, RoutedEventArgs e)
{
    //Create a DataSet from Northwind's Customers and Orders:
    System.Data.DataSet customerDS = SampleDataUtil.GetCustomersOrders(".\\SQLExpress");
    if (customerDS.Tables["Customers"] != null)
    {
        //and if available set it as data source to the grid
        this.XamDataGrid.DataSource = customerDS.Tables["Customers"].DefaultView;
    }
}
 

Now to we would need to add a custom column for our sparklines and of course provide them with data. In my case the data doesn’t have a field with a value collection so I will make myself one, but in case you have data that is already fit to be presented by the chart control – by all means, feel free to skip the next part.

As you may have noticed in the definition above there is a handle defined for the InitializeRecord event. We will use that to go through the records and provide data for the cells where the sparkline would be. But first we will add that custom column to the XamDataGrid, which in our case would be an Unbound Field added to the grid’s layouts :

 <igDP:XamDataGrid.FieldLayouts>
    <igDP:FieldLayout >
        <igDP:FieldLayout.Fields>
            <!--Unbound field definition:-->
            <igDP:UnboundField Name="Chart" Label="Freight expenses"/>
            <!--End of Unbound field definition-->
            <!--
            Below column definitions are optional as they match the data set and can be 
            auto-generated in case you skip them. Leaving them makes for better custom labels.
            -->
            <igDP:Field  Name="CustomerID" Label="Customer ID" />
            <igDP:Field  Name="CompanyName" Label="Company Name" />
            <igDP:Field  Name="ContactName" Label="Contact Name" />
            <igDP:Field  Name="Address" Label="Address" />
            <igDP:Field  Name="City" Label="City" />
            <igDP:Field  Name="Region" Label="Region" />
            <igDP:Field  Name="PostalCode" Label="Postal Code" />
            <igDP:Field  Name="Country" Label="Country" />
            <igDP:Field  Name="Phone" Label="Phone" />
            <igDP:Field  Name="Fax" Label="Fax" />
            <igDP:Field  Name="ContactTitle" Label="Contact Title" />
        </igDP:FieldLayout.Fields>
    </igDP:FieldLayout>
</igDP:XamDataGrid.FieldLayouts>
 

The name of the field is ‘Chart’ and we can now use that to set its data in code upon row initializations:

 private void XamDataGrid_InitializeRecord(object sender, InitializeRecordEventArgs e)
{
    if (e.Record is DataRecord)
    {
        //get the data record and verify it is a parent row:
        DataRecord dr = (DataRecord)e.Record;
        if (dr.HasExpandableFieldRecords)
        {
            List<int> values = new List<int>();
            foreach (ExpandableFieldRecord row in dr.ChildRecords)
            {
                RecordCollectionBase recColBase = row.ChildRecords;
                //go through all the child records
                foreach (Record childRec in recColBase)
                {
                    //and build value collections with Freight expenses for each:
                    values.Add((int)double.Parse((childRec as DataRecord).Cells["Freight"].Value.ToString()));
                }
                //build nice parsable string with the values:
                StringBuilder sb = new StringBuilder();
                values.ForEach( delegate(int value) { sb.Append(value.ToString() + " "); });
                // set that string as value of the parent's Chart cell
                dr.Cells["Chart"].Value = sb.ToString();
            }
        }
    }
}
 

At this point you should have an application with hierarchical XamDataGrid with an extra column in the parent rows containing a set of freight values. Now what is left to do is to turn those cells into XamSparkline controls!

Adding the Sparkline

The basic idea behind this is that the values for each cell have display objects called Cell Value Presenters and you can override their template. What would then be left is to set it to a Control Template with a Sparkline and bind it to the cell’s value. That of course might require a converter, so you can start by adding that in a new class implementing the IValueConverter interface. In it we’ll parse the string values to integers and return a list with their values. This is how the code for that looks like:

 class SourceConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        //skip the first (header) cell
        if ((value as CellValuePresenter).Record.DataItemIndex != -1)
        {
            //get the value, split it and parse each to int
            string values = (string)(value as CellValuePresenter).Record.Cells["Chart"].Value;
            List<int> convertedValues = new List<int>();
            List<string> separates = values.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries).ToList();
            convertedValues = separates.ConvertAll(x => int.Parse(x));
            //return the list with int values:
            return convertedValues;
        }
        return null;
    }
 
    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}
 

And the next logical step would be to add that as a resource in a proper scope in your XAML, like so:

 <local:SourceConverter x:Key="sourceConverter" />
 

The Item source of the XamSparkline will be bound to its templated parent which in our case is the Cell Value Presenter and this is why the passed value to the converter above is treated as such. It’s all very convenient as it not only provides a Record object, whose index we can check in order to skip the header (-1) row, but also exposes a Cells collection for us to grab values from.

Now once you have that final piece in place you can override the presenter’s template. You can do that by defining the style as a resource or within the Unbound field definition, that is up to you and here is the general outline of the style itself – just remember to add a key if you define it as a resource:

 <Style TargetType="{x:Type igDP:CellValuePresenter}">
      <Setter Property="OverridesDefaultStyle" Value="True"/>
      <Setter Property="Template">
          <Setter.Value>
              <ControlTemplate TargetType="{x:Type igDP:CellValuePresenter}">
                  <ig:XamSparkline 
                      ItemsSource="{Binding RelativeSource={RelativeSource TemplatedParent}, 
                                               Converter={StaticResource sourceConverter}}"
                      NormalRangeVisibility="Visible"
                      NormalRangeMinimum="0"
                      NormalRangeMaximum="50"
                      NormalRangeFill="GreenYellow"
                      HighMarkerVisibility="Visible"
                      LowMarkerVisibility="Visible"
                      ValueMemberPath=""
                      Width="150"           
                      Height="40"
                      />
              </ControlTemplate>
          </Setter.Value>
      </Setter>
  </Style>
 

This is the full code for the XamDataGrid with all the changes so far (points of interest are marked with comments):

 <igDP:XamDataGrid x:Name="XamDataGrid" InitializeRecord="XamDataGrid_InitializeRecord">
    <igDP:XamDataGrid.FieldLayouts>
        <igDP:FieldLayout >
            <igDP:FieldLayout.Fields>
            <!--Unbound field definition:-->
            <igDP:UnboundField Name="Chart" Label="Freight expenses">
                <igDP:UnboundField.Settings>
                    <igDP:FieldSettings>
                        <igDP:FieldSettings.CellValuePresenterStyle>
                            <!--Style template definition:-->
                            <Style TargetType="{x:Type igDP:CellValuePresenter}">
                                <Setter Property="OverridesDefaultStyle" Value="True"/>
                                <Setter Property="Template">
                                    <Setter.Value>
                                        <ControlTemplate TargetType="{x:Type igDP:CellValuePresenter}">
                                            <ig:XamSparkline 
                                                ItemsSource="{Binding RelativeSource={RelativeSource TemplatedParent}, 
                                                                            Converter={StaticResource sourceConverter}}"
                                                NormalRangeVisibility="Visible"
                                                NormalRangeMinimum="0"
                                                NormalRangeMaximum="50"
                                                NormalRangeFill="GreenYellow"
                                                HighMarkerVisibility="Visible"
                                                LowMarkerVisibility="Visible"
                                                ValueMemberPath=""
                                                Width="150"           
                                                Height="40"
                                                />
                                        </ControlTemplate>
                                    </Setter.Value>
                                </Setter>
                            </Style>
                            <!--End of Style template definition-->
                        </igDP:FieldSettings.CellValuePresenterStyle>
                    </igDP:FieldSettings>
                </igDP:UnboundField.Settings>
            </igDP:UnboundField>
            <!--End of Unbound field definition-->
                <!--
                Below column definitions are optional as they match the data set and can be 
                auto-generated in case you skip them. Leaving them makes for better custom labels.
                -->
                <igDP:Field  Name="CustomerID" Label="Customer ID" />
                <igDP:Field  Name="CompanyName" Label="Company Name" />
                <igDP:Field  Name="ContactName" Label="Contact Name" />
                <igDP:Field  Name="Address" Label="Address" />
                <igDP:Field  Name="City" Label="City" />
                <igDP:Field  Name="Region" Label="Region" />
                <igDP:Field  Name="PostalCode" Label="Postal Code" />
                <igDP:Field  Name="Country" Label="Country" />
                <igDP:Field  Name="Phone" Label="Phone" />
                <igDP:Field  Name="Fax" Label="Fax" />
                <igDP:Field  Name="ContactTitle" Label="Contact Title" />
            </igDP:FieldLayout.Fields>
        </igDP:FieldLayout>
    </igDP:XamDataGrid.FieldLayouts>
</igDP:XamDataGrid>
 

And the end result looks like this:

We have a normal range of up to 50 for freight expenses and you can easily tell that while some hold their values close or even below, there are users such as ‘BERGS’ that have very high values that might need some further investigation.

Conclusion

Again how you define the XamSparkline in the template is up to you – all you need in the proper data, a field to set the template of and an optional converter (depending on your data). Simple as that, you have now seen how to integrate the this control in both the cross-platform XamGrid and the WPF specific XamDataGrid with limited effort and tremendous outcome!

The obligatory calling - check out the Silverlight Data Visualization Samples online or download the local WPF Samples. Also download the demo project where you will find another style setup available(with columns as display type and the nice blue trendline) and since curiosity is such a nice thing to appeal to, here a teaser screenshot for that one too:

The solution has been cleaned, so make sure assembly references are all in check and build.

Our Spakline integrated in a Grid

dpetev — Tue, 21 Feb 2012 07:37:00 GMT

With 11.2 we introduced the XamSparkline control, which is in essence a fully-functional chart but with the major addition of being extremely compact. This is so important as it is intended to fit inside a grid cell. While this control is still CTP in the current release, there’s nothing stopping you from experimenting and making use of its functionality right now. And just in case you missed – get to know this minimalistic control starting with the Introduction to the Infragistics Sparkline Control blog post by Atanas Dyulgerov. In it you can learn the basics of the control – while simple is yet another description you can give this XAML control, you will find it doesn’t really leave you wanting more – it is feature rich as well. The XamSparkline can display numeric and date entries in four different chart types, it can display a range bar which basically visualizes the area with acceptable or goal values. Then there’s also the array of highly customizable markers the Sparkline supports out of the box and a trend line with multiple calculation methods. And, yes, all that can fit in very limited space (e.g. inside a grid) and prove to have extremely high information per pixel ratio

At this point, if you have been looking at our Silverlight Data Visualization Samples or the downloadable WPF version, you might be saying “Yes, I understand it’s meant to fit inside a grid and you keep saying that but I don’t see it anywhere!”. Not to worry – this is exactly what will be shown in this article.

Imagine a scenario where you have hierarchical data displayed effortlessly by a XamGrid, but consider this – what if your rows have 20 or more child entries and you need to find just some that have some sort of an issue? How would you get the required data fast, how can you analyse those entries fast? The natural answer for the latter is usually a visual representation - i.e a chart and in our case that would be a XamSparkline without a doubt. And since it is part of both Data Visualization products and because our XamGrid is now also cross-platform, this is done very easily and is also portable between the platforms. Here is the end result we are after:

As you can see in the child entries the values from the last two columns (the one that is a bit cut is the UnitsOnOrder, sorry about that) are presented by the chart as follows: 39, –23, 20. This makes spotting negative values very easy.

Setting up

First things first, taking into account this is a combination of Line of Business (LoB) and Data Visualization (DV) controls means you will need one of each – either a combination of NetAdvantage for WPF LoB and DV or NetAdvantage for Silverlight LoB plus DV, but then again trial packages will also do.

You will also need data. Following the scenario from above you would need hierarchical data of some kind. For simplicity's sake in my example I will use the DataUtil class that is available from our Help Topics in both Visual Basic and C#. Speaking of which you can as always find tons of useful information in the XamGrid Online Help for Silverlight or WPF, even though it’s a shared XAML control, so those links are somewhat just to indulge your preferences.

Grab the preferred version of the DataUtil class and add it to your project – keep in mind the namespace when copying, which I’d suggest to change to your project’s namespace. When that is done link the namespace to your XAML page/window:

  xmlns:local="clr-namespace:SparklineInXamGrid"
 

In that case ‘SparklineInXamGrid’ is the namespace of my project. Then you can also add the Infragistics namespace:

 xmlns:ig="http://schemas.infragistics.com/xaml"
 

This namespace is the only needed for this case in Silverlight and WPF because both the XamSparkline and the XamGrid are shared XAML controls for both platforms. There are also references to a few assemblies required - InfragisticsSL4.v11.2.dll, InfragisticsSL4.Controls.Grids.XamGrid.v11.2.dll, InfragisticsSL4.Controls.Menus.XamMenu.v11.2.dll for Silverlight as thier naming suggests. The assemblies for WPF follow the same model - InfragisticsWPF4.v11.2.dll, InfragisticsWPF4.Controls.Grids.XamGrid.v11.2.dll, InfragisticsWPF4.Controls.Menu.XamMenu.v11.2.dll, with the addition of InfragisticsWPF4.DataManager.v11.2.dll.

At this point you have a project set up to start building, so begin by adding the DataUtil as a resource in a scope you see fit:

  <local:DataUtil x:Key="data"/>
 

Now you can add the XamGrid control and bind it to the data’s hierarchical collection – the file provides a combination of Categories and Products we can use:

 <ig:XamGrid 
    ItemsSource="{Binding Source={StaticResource data},Path=CategoriesAndProducts}" 
    Margin="20" 
    Name="xamGrid"/>
 

The XamGrid will generate the columns based on the data and we can rely on that for this demo, as our goal is not fine-tuning the grid, for which you can again refer to the Help docs.

So far you should have a working application with hierarchical grid.

Adding the Sparkline

Again let’s go back to our scenario – you can now see in a relatively small scale ( the DataUtil is only a small data sample) how we can take advantage of compressed data. Say we want to manage easily the balance of products we have in stock and on order. That means a few values per category in our small scale example, but... imagine if you had 50 products in a category and you need to find those with low amounts in stock yet many on order so you can replenish their numbers in some way. This is where our Sparkline will come – to provide this crucial info for each category.

For that goal we can create an Unbound Column in our grid to hold the values to be displayed by XamSparkline controls. And to have those values we will set them using the converter we have to implement for the Unbound Column. So add a class to your project that would implement the IValueConverter Interface:

 namespace SparklineInXamGrid
{
    public class SourceConverter : IValueConverter
    {
 
        public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            List<int> convertedValues = new List<int>();
            foreach (Product prod in (value as Category).Products)
            {
                convertedValues.Add(prod.UnitsInStock - prod.UnitsOnOrder);
            }
            return convertedValues;
        }
 
        public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
        {
            throw new NotImplementedException();
        }
    }
}
 

And add that as a resource to your XAML (now you see why we changed the namespace of the DataUtil):

 <local:SourceConverter x:Key="SourceConverter"></local:SourceConverter>
 

As you might have noticed already the value passed to the Convert method is used as an instance of the class Category, which is defined in our DataUtil class. And of course, the value this converter will receive would be from the context of the current row, which without a doubt would be the Category from the CategoryAndProducts collection. And better yet, it exposes a collection of products with their UnitsInStock and UnitsOnOrder properties we would use to calculate the balance and create a collection from – in this case a List, but a simple array of integers would do too. The returned values would become the ‘Value’ property of the Unbound Column. Now for the column itself:

 <ig:UnboundColumn Key="Balance" 
                  ValueConverter="{StaticResource SourceConverter}"
                  IsSortable="False" 
                  IsSummable="False"/>
 

IsSortable and IsSummable are false by default as additional efforts on your side are required for those to work with Unbound Columns, so this above is just to remind and stress you might not need those in our case but you also don’t get them by default either. As you can see the Value converter is set for the whole column so we now have the values for each cell. What is left to do is define an Item template for the column that would consist of our XamSparkline and the finished code looks like so:

 <Grid x:Name="LayoutRoot" Background="White">
    <ig:XamGrid ItemsSource="{Binding Source={StaticResource data},Path=CategoriesAndProducts}" 
                Margin="20" Name="xamGrid">
        <ig:XamGrid.Columns>
            <ig:UnboundColumn Key="Balance" ValueConverter="{StaticResource SourceConverter}"
                              IsSortable="False" IsSummable="False">
                <ig:UnboundColumn.ItemTemplate>
                    <DataTemplate>
                        <ig:XamSparkline ItemsSource="{Binding Value}" 
                                         ValueMemberPath=""
                                         TrendLineType="LogarithmicFit"
                                         TrendLineBrush="#FF14AAE2"
                                         DisplayType="Column"
                                         Width="200"                
                                         Height="60"/>
                    </DataTemplate>
                </ig:UnboundColumn.ItemTemplate>
            </ig:UnboundColumn>
        </ig:XamGrid.Columns>
    </ig:XamGrid>
</Grid>
 

The ItemSource of the control is bound to the Value property of the Unbound Column as explained above and since it’s a simple collection we don’t have a ValueMemberPath so we leave that one empty. The rest is up to you – we have columns with a nice blue trend line. This is the template used in the screenshot from the start of the blog and here’s yet another one using the Line chart type along with a Normal range defined from –5 to 30 ( I made that up naturally) and some nice High and Low markers.

Using normal range is only useful if the data points don’t have huge variations as you are setting one range for all charts and on some due to their values it just might not be visible, so use with caution. Anyway, it does look nice (the green-ish area) and it can really help spot some odd fluctuations in your values:

And the temple for that is:

 <ig:UnboundColumn.ItemTemplate>
    <DataTemplate>
        <ig:XamSparkline ItemsSource="{Binding Value}" 
                         ValueMemberPath=""
                         DisplayType="Line"
                         NormalRangeVisibility="Visible"
                         NormalRangeFill="GreenYellow"
                         NormalRangeMinimum="-5"
                         NormalRangeMaximum="30"
                         LowMarkerVisibility="Visible"
                         HighMarkerVisibility="Visible"
                         Width="200"                
                         Height="60"/>
    </DataTemplate>
</ig:UnboundColumn.ItemTemplate>
 

Conclusion

The XamSparkline might be miniature but it’s built with fitting small areas in mind while still being very data-intensive. It makes a great combination with the XamGrid and since they are both shared across XAML product lines, the code for the latter can be easily moved back and forth. And such cooperation is surprisingly easy to get going – a single Unbound Column, a converter and an item template holding the Sparkline. And don’t be fooled by the few data points – this control is well capable of displaying a lot more in that same limited space:

And this is ‘just’ 30 data points and.. well, there’s clearly room for more

Yet again, check out the Silverlight Data Visualization Samples online or download the local WPF Samples.

As always you can download the demo project for this blog – this time containing both Silverlight and WPF projects. The solution has been cleaned, so make sure assembly references are all in check and build.