Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#561 closed defect (fixed)

SortableTable render() and parseData() semantics

Reported by: [email protected] Owned by: [email protected]
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)

SortableTableRender-Patch.txt (581 bytes) - added by [email protected] 15 years ago.
patch for this ticket

Download all attachments as: .zip

Change History (4)

Changed 15 years ago by [email protected]

patch for this ticket

comment:1 Changed 15 years ago by anonymous

Owner: changed from anonymous to [email protected]

comment:2 Changed 15 years ago by [email protected]

Resolution: fixed
Status: newclosed

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);

comment:3 Changed 14 years ago by (none)

Milestone: 0.3release

Milestone 0.3release deleted

Note: See TracTickets for help on using tickets.