We have a hidden column that we require our grids to be sorted on. The column contains information that the user cannot see or interact with.
The problem is that if we call igGridSorting("sortColumn" on this hidden column, a javascript exception is thrown.
I have traced the problem down to the following code in infragistics.ui.grid.sorting.js:
// M.H. 19 July 2012 Fix for bug #113505 if (this.grid._detachedHeaderCells && isSingleMode && cs[i].columnKey && this.grid._detachedHeaderCells[cs[i].columnKey]) { if (cs[i].currentSortDirection !== undefined && cs[i].currentSortDirection !== null) { delete cs[i].currentSortDirection; } It seems that any column specified as a hidden column is added to the detachedHeaderCells array, which causes the sorting on the column to be removed, leading to js exception when subsequent code tries to access to currentSortDirection.Changing the column to unhidden resolves the issue, but breaks our application requirement. Has this been fixed or is there any workaround to prevent adding the hidden sort column to the detachedHeaderCells array?(We have to use programmatic sort after inserting a row because inserting an entry directly into the datasource results in a loss of the transaction data for that row.)
Hello Karl, I have opened a support ticket with ID - CAS-110268-R3B7V8 which is visible for you if you log in our website and go to Account > Support activity. We will continue our communication regarding the issue through the support ticket.
Even though the developers have stated this is "as designed", there is a trivial fix to the problem. Pass the current s in method sortColumn to _clearSortStates, then modify the following code in _clearSortStates:
// M.H. 19 July 2012 Fix for bug #113505 if (this.grid._detachedHeaderCells && isSingleMode && cs[i].columnKey && this.grid._detachedHeaderCells[cs[i].columnKey]) { if (cs[i].currentSortDirection !== undefined && cs[i].currentSortDirection !== null) { delete cs[i].currentSortDirection; } this._clearHeaderCellSortState(this.grid._detachedHeaderCells[cs[i].columnKey][0]); }to be:
// M.H. 19 July 2012 Fix for bug #113505 if (this.grid._detachedHeaderCells && isSingleMode && cs[i].columnKey && this.grid._detachedHeaderCells[cs[i].columnKey]) { if (typeof s != 'undefined' && s && cs[i].columnKey == s.columnKey) { // We are sorting on a hidden column and this is the hidden column, so don't clear the sort info } else { if (cs[i].currentSortDirection !== undefined && cs[i].currentSortDirection !== null) { delete cs[i].currentSortDirection; } this._clearHeaderCellSortState(this.grid._detachedHeaderCells[cs[i].columnKey][0]); } }
Hi Karl,
As a workaround to your issue I would suggest to sort the column in the igDataSource and then rebind the grid.
Modifying the source code yourself will harden the process of upgrading to newer Ignite UI version.
Best regards,
Martin Pavlov
Infragistics, Inc.
One additional comment: one of the reasons that I included the source code modifications is that I see the trend continuing that started with the Ultra product line: when an issue is reported, the developers quite often rejected it or said that's the way it will be rather than taking the time to understand the problem and look for a solution.
As I pointed out in the source code, it is a very easy fix that I would hope would have been obvious to the development staff.
For the ultra product line, we had many reported issues rejected that were critical to the proper operation of our application. Because of this, we had approximately 40 manual fixes that we had to apply to the javascript after each release.
I have much higher hopes for Ignite. Our customers expect a high level of functionality, and we are relying Ignite to help us provide that functionality
Hello Karl,Thank you for your feedback. It is helping us to see what are our customer's concerns and suggestion so we can continue our constant improvement.
Hello Louis,
I'm just checking whether you need any further assistance regarding this matter. Please feel free to contact us in this case.
Sincerely,
Tsanna
And a quick, but important update: The developers have devised a way to fix the issue and as I said earlier, different people have different degree of understanding of the code so their fix is not exactly the same as the one you have suggested.You are free to use your fix of course, but do keep in mind that our developers' will be available in the next Service Release.Cheers,Bobby
Hey Karl,I'll try to address as many of the point's you've made as possible so sit tight :)
Karl Costenbader said:We have a hidden column that we require our grids to be sorted on. The column contains information that the user cannot see or interact with.
Assuming you'd like the end user to sort the hidden column, then I'd suggest the following setup (demonstated by sample-12.2.htm):
Karl Costenbader said:The problem is that if we call igGridSorting("sortColumn" on this hidden column, a javascript exception is thrown
This may sound like an excuse, but I mean it as an explanation: performing such an operation (sorting a column) via the API and through the UI follows slightly different logic. This is what's the matter here. The sortColumn() API method was introduced as part of the Sorting feature back in the 1st incarnation of Ignite UI (2011.1). There was no Hiding feature back then so the API method was envisioned to work with visible columns because it sort of imitates end user behavior - sorting a column visible to the end user. However, even back then the "multi" (a.k.a multiple column) sorting mode made it possible to operate on hidden columns. Yep, that was because in "multi" sorting mode, the problematic internal method that you mentioned (_clearSortStates) is never called. I'm not sure what the risk of applying fixes to _clearSortStates's body is, but using the "multi" sorting mode bypasses the problem immediately and unless you have something against using (a requirement perhaps?), I strongly suggest setting it.
Martin Pavlov"] As a workaround to your issue I would suggest to sort the column in the igDataSource and then rebind the grid. Well now, this seems a rather tough one to implement, due to the requirement of more in-depth working knowledge of the igGrid, even though it's a viable solution nonetheless.In this case Martin relies on a presumption that the developer is aware of the igGrid's internal igDataSource object and the ability to access a jQuery widget's internals using the .data() jQuery method. However, I personally find this approach a bit tedious and I'd like to avoid it so I for now I won't attach an HTML sample showcasing it. Karl Costenbader said:I have found it to be very difficult to discover information for Ignite versus previous Infragistics products How so? Can you please give us an example of such a predicament?I'd say that the API documentation (it's autogenerated based on the code of the Ignite UI widgets) and the Developer's Guide amount to a reasonable wealth of knowledge of the product. Karl Costenbader said:For example, in the local help (which I often reference while disconnected), searching for a term and then selecting it takes you to the very unhelpful main navigation page as opposed to the actual term. Oh, I agree that the Developer's Guide is a real idiot when it comes to indexing content, but that's a problem we are aware of and will resolve in the future (the help generation tools we use are somewhat dated and I'm not sure if switching over to a new set of tools will be an easy feat). Karl Costenbader said:In addition, the hiearchy of classes (i.e. columnSettings) is buried and difficult to understand. Are you referring to the Sorting feature's JS code (direct API reference to it) or the MVC wrapper for the Sorting feature's columnSettings? Can you also give me an example of what would you rather expect from the help docs when looking for such details? Karl Costenbader said:And finally, the examples are decent for relatively trivial items, but don't go far enough in explaining more complex issues. A perfect example is the conditional row style example. Although the example shows the code, it would be MUCH more useful to explain precisely what the code does rather than having the user try to piece together what is happening from the code sample. I'm afraid that there is a misunderstanding on what the purpose of those samples is. They are meant to serve as simple showcases, demonstrating an operation or behavior so that a person can get a sense of the experience the end user would have when operating with one of the controls. By the way we are still moving towards the goal of making the samples even simpler.Yes, this is a part of the policy for the official samples - if you take a look at our competitors' samples, you will see that they are following this ideology as well. Feel free to correct me if I'm wrong :). Karl Costenbader said:In otherwords, explain that each cell must have the style applied separately in order to style the entire row. It is not easy to grasp this concept from the sample code without performing an in-depth analysis of how the conditions are applied. We have a thing (and implementation) in mind that will hopefully become public soon that will be aligned with such requirements - more programmable samples and in-depth explanations. So far the only thing that comes close to this (and will continue to be) are our blogs where there articles with more complex samples and detailed explanations. NB: I strongly recommend following Damyan Petev's blog. IMO, he writes the best samples and explanations for Ignite UI that can satisfy any developer's needs. Give the blog a read - you won't disappointed ;).Karl Costenbader said:One additional comment: one of the reasons that I included the source code modifications is that I see the trend continuing that started with the Ultra product line: when an issue is reported, the developers quite often rejected it or said that's the way it will be rather than taking the time to understand the problem and look for a solution. As I pointed out in the source code, it is a very easy fix that I would hope would have been obvious to the development staff.You seem to be quite the clairvoyant, Karl :(. I saw the current status of the development issue and yes, the solution to it is to forbid (with an appropriate exception at least) calling sortColumn() (in "single" mode) of a hidden columns. I'll speak with the developer myself and I'll try to negotiate applying your suggested fix instead. I'll let you know how this goes. Karl Costenbader said:For the ultra product line, we had many reported issues rejected that were critical to the proper operation of our application. I'd like to say that fixes rely on different factors such as cross-browser compatibility, time and manpower that we can allocate for bug fixing and testing and each developer's personal scope of understanding of the code. So this is why sometimes suggested fixes have to be politely rejected in favor of updating the known limitations list. It's complicated - no better excuse I'm afraid :(. Karl Costenbader said:I have much higher hopes for Ignite. Our customers expect a high level of functionality, and we are relying Ignite to help us provide that functionality Thank you for your trust. As a person who has been testing and working with the developers of Ignite UI since it came out with the 2011.1 volume release, I'd have to say that it's a good product that's becoming even better. Yes, there are bumps and lumps along the road, but we are giving our best to make sure the quality of the controls is on par with the expectations of our customer-developers as well as their end users.PS: Sorry for the wall of text - it's how I roll* and I hope the details here are of value to you!Cheers!Bobby
Well now, this seems a rather tough one to implement, due to the requirement of more in-depth working knowledge of the igGrid, even though it's a viable solution nonetheless.In this case Martin relies on a presumption that the developer is aware of the igGrid's internal igDataSource object and the ability to access a jQuery widget's internals using the .data() jQuery method. However, I personally find this approach a bit tedious and I'd like to avoid it so I for now I won't attach an HTML sample showcasing it.
Karl Costenbader said:I have found it to be very difficult to discover information for Ignite versus previous Infragistics products
How so? Can you please give us an example of such a predicament?I'd say that the API documentation (it's autogenerated based on the code of the Ignite UI widgets) and the Developer's Guide amount to a reasonable wealth of knowledge of the product.
Karl Costenbader said:For example, in the local help (which I often reference while disconnected), searching for a term and then selecting it takes you to the very unhelpful main navigation page as opposed to the actual term.
Oh, I agree that the Developer's Guide is a real idiot when it comes to indexing content, but that's a problem we are aware of and will resolve in the future (the help generation tools we use are somewhat dated and I'm not sure if switching over to a new set of tools will be an easy feat).
Karl Costenbader said:In addition, the hiearchy of classes (i.e. columnSettings) is buried and difficult to understand.
Are you referring to the Sorting feature's JS code (direct API reference to it) or the MVC wrapper for the Sorting feature's columnSettings? Can you also give me an example of what would you rather expect from the help docs when looking for such details?
Karl Costenbader said:And finally, the examples are decent for relatively trivial items, but don't go far enough in explaining more complex issues. A perfect example is the conditional row style example. Although the example shows the code, it would be MUCH more useful to explain precisely what the code does rather than having the user try to piece together what is happening from the code sample.
I'm afraid that there is a misunderstanding on what the purpose of those samples is. They are meant to serve as simple showcases, demonstrating an operation or behavior so that a person can get a sense of the experience the end user would have when operating with one of the controls. By the way we are still moving towards the goal of making the samples even simpler.Yes, this is a part of the policy for the official samples - if you take a look at our competitors' samples, you will see that they are following this ideology as well. Feel free to correct me if I'm wrong :).
Karl Costenbader said:In otherwords, explain that each cell must have the style applied separately in order to style the entire row. It is not easy to grasp this concept from the sample code without performing an in-depth analysis of how the conditions are applied.
We have a thing (and implementation) in mind that will hopefully become public soon that will be aligned with such requirements - more programmable samples and in-depth explanations. So far the only thing that comes close to this (and will continue to be) are our blogs where there articles with more complex samples and detailed explanations. NB: I strongly recommend following Damyan Petev's blog. IMO, he writes the best samples and explanations for Ignite UI that can satisfy any developer's needs. Give the blog a read - you won't disappointed ;).
Karl Costenbader said:One additional comment: one of the reasons that I included the source code modifications is that I see the trend continuing that started with the Ultra product line: when an issue is reported, the developers quite often rejected it or said that's the way it will be rather than taking the time to understand the problem and look for a solution.
As I pointed out in the source code, it is a very easy fix that I would hope would have been obvious to the development staff.You seem to be quite the clairvoyant, Karl :(. I saw the current status of the development issue and yes, the solution to it is to forbid (with an appropriate exception at least) calling sortColumn() (in "single" mode) of a hidden columns. I'll speak with the developer myself and I'll try to negotiate applying your suggested fix instead. I'll let you know how this goes.
Karl Costenbader said:For the ultra product line, we had many reported issues rejected that were critical to the proper operation of our application.
I'd like to say that fixes rely on different factors such as cross-browser compatibility, time and manpower that we can allocate for bug fixing and testing and each developer's personal scope of understanding of the code. So this is why sometimes suggested fixes have to be politely rejected in favor of updating the known limitations list. It's complicated - no better excuse I'm afraid :(.
Karl Costenbader said:I have much higher hopes for Ignite. Our customers expect a high level of functionality, and we are relying Ignite to help us provide that functionality
Thank you for your trust. As a person who has been testing and working with the developers of Ignite UI since it came out with the 2011.1 volume release, I'd have to say that it's a good product that's becoming even better. Yes, there are bumps and lumps along the road, but we are giving our best to make sure the quality of the controls is on par with the expectations of our customer-developers as well as their end users.PS: Sorry for the wall of text - it's how I roll* and I hope the details here are of value to you!Cheers!Bobby