This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 160765 - Support passing a data through XAM transactions
Summary: Support passing a data through XAM transactions
Status: NEW
Alias: None
Product: xml
Classification: Unclassified
Component: XAM (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-20 19:37 UTC by Nikita Krjukov
Modified: 2011-11-30 16:22 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikita Krjukov 2009-03-20 19:37:26 UTC
Sometimes it is necessary to identify an XAM transaction or pass a user data through it. 
For example, it can be very helpful to prevent redundant cycling while changing an XAM model. 
It is suggested to modify transaction related methods the following way:

-- Add a new method 
     void startTransaction(Object transactionDataObject);

-- Change the method
     void endTransaction(); 
   to 
     Object endTransaction();
   The new return value will be the same as was passed to the startTransaction(Object ...) method.
   If the old method startTransaction() is called then the null has to be returned.

-- Add a new method 
     Object getTransactionDataObject();
Comment 1 Nikita Krjukov 2009-04-03 20:26:00 UTC
Correction: 
It's not necessary to change the void endTransaction() method because it's usually located together with the
startTransaction(). So the transactionDataObject has to be visible there.
Comment 2 Nikita Krjukov 2009-04-03 20:37:00 UTC
Additional motivation: 

I imply the following standard use-case when the suggested modification can be very helpful:

-- There are a XAM based model and a UI client, which works with the model. 
-- The client has to be updated when the model has changed. 
-- The client can modify the model. 
-- The model can be changed externally and such changes have to affect the UI client. 
-- The model doesn't know who changes it. 
-- The UI client doesn't know if it was changed by a user or by a modification in the model. 

In such conditions it is easy to get cycling when the model modifies the client and vice versa.