Trade Restoration
This package contains classes to facilitate in the restoration of Trade
s.
This will occur when the server sends a specific message to restore a particular
trade. There are two scenarios that can occur on the client side.
- The trade is known on the client (for example a trade object in an open ticket), so a new trade object won't be created.
- The trade is not known on the client, so a new trade object will be created to restore the trade.
Since the trade exists in the first scenario, any object that wishes to listen
for trade restoration events should add a listener directly to the Trade using
module:caplin/trading/trademodel/Trade#addTradeRestoredListener
.
For the second scenario, listeners can be added to the TradeService
class
using module:caplin/trading/service/TradeService#addTradeRestoredListener
. Note that
the module:caplin/trading/restoration/TradeRestoreEvent#getTrade
method will return null
when the module:caplin/trading/restoration/TradeRestoredListener#beforeTradeRestored
event
is fired in this case, since the trade object won't be created yet.
Restoration Event Order
When a trade is restored, there is an order in which components of the trade are restored.-
beforeTradeRestored()
firedmodule:caplin/trading/restoration/TradeRestoredListener
s
-
tradeRestored()
firedmodule:caplin/trading/restoration/TradeRestoredListener
s
-
structureChanged()
fired onmodule:caplin/trading/trademodel/StructureChangedListener
s
-
dataFieldChanged()
fired onmodule:caplin/trading/trademodel/DataFieldChangedListener
s
Limitations
Currently the Java Trading Data Source library can only send 1 leg addition at a time. Therefore when the trade is restored it will have at most 1 leg. If the trade already exists on the client and contains more than 1 leg before restoration, all legs except the restored leg will be removed. It is up to the implementors of the Trading Data Source library to add additional legs via another state change if they are required for the trade.