Columnize by key/value leaving "null" columns in Refine's rowModel

[GoogleCodeExporter]

The "Columnize by key/value columns" feature appears to work visually (I've run 
some extreme use cases and it's handled them perfectly), but when inspecting 
Refine's row model under the bonnet, I was surprised to see that there were an 
incorrect number of cell indexes per row, and some contained "null" values - 
which were not present in the data table.

These cell indexes match up for every row - so if they were represented in the 
data table, they would appear as blank columns.

Attached is a screen capture of me columnizing 5 rows of data, transforming the 
energy type values in column "Energy type" into their own columns that store 
their corresponding measurements. I highlight the null values in my browser's 
DOM inspection tab.

Original issue reported on code.google.com by danpaulsmith on 23 Nov 2011 at 11:37

Attachments:

• ColumnizeKeyValueBug.m4v

[GoogleCodeExporter]

Version 2386

Original comment by danpaulsmith on 23 Nov 2011 at 2:38

[GoogleCodeExporter]

Original comment by tfmorris on 26 Nov 2011 at 6:23

• Changed state: Accepted

[GoogleCodeExporter]

Dan, I believe this is working as designed. Cells are not stored in the order 
in which they are displayed. Rather, the column model specifies which column 
corresponds to which cell index. There is a variable per project to keep track 
of essentially the longest cell array among all rows, so that the next time you 
need to create a new column, we know which cell index it would correspond to. 
As you perform operations that create columns, the cell array for each row 
grows. What we need is an operation for compacting the project.

Original comment by dfhu...@gmail.com on 27 Nov 2011 at 10:54

[GoogleCodeExporter]

OK, I've changed our code to handle null values/columns.

I think a compacting operation would make sense - either exclusively for the 
columnize operation or as a command that could be manually initiated at any 
point.

Thanks

Original comment by danpaulsmith on 28 Nov 2011 at 11:03

[GoogleCodeExporter]

Please see issue 498.

Original comment by dfhu...@gmail.com on 29 Nov 2011 at 7:58

• Changed state: WontFix