Ticket #561 (closed defect: fixed)
SortableTable render() and parseData() semantics
| Reported by: | jkuhnert@… | Owned by: | ttrenka@… |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | General | Version: | 0.3 |
| Severity: | normal | Keywords: | |
| Cc: | jkuhnert@… |
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();