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:

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

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:

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:

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:

“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:

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:

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:

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

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:

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.

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):

Will produce the following response to the client:

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?

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:

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:

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
  • • Merge Unbound Columns property and Performance implications
    • Merging Unbound Columns and setting values on data-bound client event
    • Client-side methods to get Unbound columns and their values
  • Using unbound columns with advanced column options such as Templating or formatting.

• You can instantly try the the feature with the following JSFiddle-s:
  • Updating and setting unbound values. Transactions.
  • Setting unbound values in both parent and child layouts in the Hierarchical Grid
• 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.