#561 closed defect (fixed)
SortableTable render() and parseData() semantics
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | high | Milestone: | |
Component: | General | Version: | 0.3 |
Keywords: | Cc: | [email protected]… | |
Blocked By: | Blocking: |
Description
I know Tom should be handling this, but since he's going to be tied up traveling for the next few days and I really really need this now-ish I'm hoping it might get in anyways? I'm ok with him pummeling me when he gets back on Monday.
This patch takes out the parseDataFromTable call in the render() function, for two reasons:
1) ParseDataFromTable? is already getting called in postCreate. So calling that, then render() in postCreate effectively makes it do twice as much work.
2) Trying to use the parseData() function becomes completely useless as whatever data you have set gets obliterated in the render() function by it calling parseDataFromTable() again.
I'm fairly confident this patch should be ok. The only catch is that if people were previously expecting showSelection() to operate without having to call it they will now have to do this themselves...Ie:
table.parseData<>; table.render(); table.showSelection();
Attachments (1)
Change History (4)
Changed 15 years ago by
Attachment: | SortableTableRender-Patch.txt added |
---|
comment:1 Changed 15 years ago by
Owner: | changed from anonymous to [email protected]… |
---|
comment:2 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Solved. Basically if you don't want to preserve the state of data in the SortableTable?, pass "true" (the bool, not the string) to the render method, like so:
w.parseData(arrJSON); w.render(true);
patch for this ticket