When to call fireTableRow events in a TableModel?

Question

Hoi All,
Could somebody confirm that the statement are true?
Propagate fireTableRowsUpdated in a TableModel AFTER+ updating the row in the model so that getValueAt and getRowValue(rowIndex) in the receiving view can fetch the update row based on the received row index in the fireTableRowsUpdated event using the view's getModel().getValueAt().
Propagate fireTableRowsDeleted in a TableModel BEFORE+ removing the row from the model so that the receiving view can fetch the to-be-deteled row based on the received row index in the fireTableRowsDeleted event using the view's getModel().getValueAt().
Propagate fireTableRowsInserted in a TableModel AFTER+ adding the row to the model so that the receiving view can fetch the inserted row based on the received row index in the fireTableRowsInserted event using the view's getModel().getValueAt().
Thnx
A

Answer 1

Hi Camickr,
In Java5 a fireTableModelEvent that is fired from a tableModel will 'directly'be processed by the JTable view (it is not queued) , so therefore the JTable view will 'see/view 'the tablemodel as it is just before fire-ing the tablemodelevent: therefore it is significant the exact place where you are invoking the fireEvent. This has caused me grief in my Java5 implementation because I've build a stack of up to 3 table models ( using Java 5 Generics) :
1) generic table model
2) generic table filter
3) generic table sorter
where I can make combinations like :
* only table model
* table model + filter model
* table model + filter model + sorting model
each model must fire the same (mapped) row numbers for insert/delete and update table model events becuase the view (JTable) doesn't know which model combination is used. I also wrote a generic table selection that also receives the table model event from the top table model stack (so either sorter, filter or table model) .
My idea was that amendments to the table model ( there is always a table model a to bottum of that above mentioned stack) will propagate through filter model which maps the table model first and last row event which propagate to the filtered row number to the sorting model that maps the table model event row numbers from the filter to a mapped row number based on the sorting of the rows (in the filtered table model) which propagate then finally to the JTable view.
So far so good for Java5.
Now back to your remark "new event gets generated" suggests that an async event is generated, queued onto the event thread. Is this new in Java6 or can you point me to some articles and/or code/documentation that describes this process?
Looking forward to your reply.
Andr�