Dynamic View Services > Specifying Dynamic View Types > Collectors > Editing a Collector with Local Feedback
 
Editing a Collector with Local Feedback
It is sometimes necessary to obtain a local feedback of the additions or deletions performed on a collector, without waiting for feedback from notification by the server. Such local feedback is especially useful when using the component transaction mechanism (see “Interaction Cycles”.). A component may decide to perform an extended set of modifications on its representations before committing the whole transaction to the server.
When removing a representation object from a collector, you can perform the local feedback by deleting this object yourself. You must indicate this by setting the last parameter value to IlsTrue in the call to IlsRpObject::onRmFromCollection. For instance, you can implement this kind of callback on TableR :
void TableR::onRemoveRow(RowR& row)
{
row.onRmFromCollection(*this,getAttributeId("rows"),IlsTrue);
}
To obtain a local feedback for cutting-and-pasting a row from one table to another, you must execute the following steps:
1. Create a new row as a copy of the original row.
This new row represents the row in its target table. The invoked RowR constructor should itself execute the following base class constructor:
RowR::RowR(const RowR& original_row,IlsRepresentation& repres)
: IlsRpObject(repres,*original_row.getModel())
{ ..}
2. Map the new row to the same server object as the row in the original table. This is done by executing the following call:
new_row.setMapping(original_row)
This call prevents the server from creating a new server object when the row is added to a collector.
3. Add the new row to the collector of the target table:
new_row.onAddToCollection(target_table,getAttributeId(“rows”));
4. Remove the original row from its table by calling the following function:
original_row.onRmFromCollection(original_table,
getAttributeId(“rows”),
IlsTrue);
5. Delete the original row.
Note: All these operations should be enclosed in a component-to-server transaction, so that no requests are sent to the server until the transaction is committed or rolled back. See “Interaction Cycles”..
When committed, the transaction may fail on the server side. In this case, the server notifies the destruction of the new row and the re-creation of the old one.
The same happens if the transaction is rolled back by the component, unless the local rollback mode has been selected (see section “Transaction Control” in the IlsMvComponent class description, in the Rogue Wave® Server Reference Manual).
In this case, the appropriate rollback must be initiated by the component.

Version 5.8
Copyright © 2014, Rogue Wave Software, Inc. All Rights Reserved.