Changing display column for Table View doesn't update input fields

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open Documents table in Oxrep
2. Change viewed column for docsite from id to sitename

What is the expected output? What do you see instead?
The values in the docsite column should change, instead they remain the same; 
this is because the JS code is looking for a select instead of an input; this 
is related to fixing issue 629.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by scott.br...@gmail.com on 11 Mar 2015 at 2:45

[GoogleCodeExporter]

Hi Scott, thanks for dealing with that OxRep issue. I think we should 
prioritize this as critical as well, as we had no end of grief from our early 
adopters until we implemented it! I hope the two fixes are not mutually 
exclusive.

Original comment by jajwil...@gmail.com on 11 Mar 2015 at 4:29

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

No, I just need to change the JavaScript to modify input as well as select 
fields.

Original comment by scott.br...@gmail.com on 11 Mar 2015 at 4:32

[GoogleCodeExporter]

Checked the AJAX code that gets called when you use the heading drop downs, and 
it returns all the select options for the column whenever you change the label 
selection .... all 50000 of them for some columns :(

I'll have to rewrite the code to just return tuples for the rows in the current 
view (i.e. about 100 rows) so not as quick a fix as I hoped.

Original comment by scott.br...@gmail.com on 11 Mar 2015 at 8:12

[GoogleCodeExporter]

I've done a bunch of work on this, and created a new utility method for 
retrieving just the FKs and labels for the rows in the view (so a max of 100 
tuples, rather than thousands of rows). However I still need to modify the JS 
code to call it with the correct parameters, and then use it to modify the rows 
in the UI. However, when complete this should give us better performance as 
well as returning the functionality we lost when fixing issue 629.

Original comment by scott.br...@gmail.com on 12 Mar 2015 at 5:42

[GoogleCodeExporter]

Original comment by scott.br...@gmail.com on 13 Mar 2015 at 9:32

• Changed state: Started

[GoogleCodeExporter]

Progress update... it looks like this whole "load the table and everything 
related to it, regardless of how many million rows it is" is baked into the DNA 
of this view as its used for all kinds of things like the scripts for 
committing changes.

This thing needs a major rewrite or its going to crash the browser for most 
real databases.

Original comment by scott.br...@gmail.com on 13 Mar 2015 at 11:51