EMF/MQ, MT, and VF 1.2/New and Noteworthy
EMF Model Query, Model Transaction, and Validation Framework Release 1.2 New and Noteworthy Items.
For more details about the milestone-by-milestone development plan, see the 1.2 draft plan.
Back to Eclipse Modeling Framework.
Transaction: Support for Open Composite Operations
The Workspace Integration layer's IOperationHistory-based CommandStack implementation now supports open composite operations. Now, a CompositeEMFOperation can safely implement the ICompositeOperation interface to be "opened" on the history while other operations are executed within its scope. The editing domain will correctly attach ResourceUndoContexts to the composite when it completes, ensuring that it appears on the Undo menu of any editor on the affected Resources.
This works also for AbstractEMFOperations that are executed while a non-EMF composite operation is open on the history.
Transaction: Workspace Validate-Edit Support
Transactions perform a new validate-edit step in the validation phase of commit. When a root transaction commits, it now checks that the resources affected by the transaction are writable or can be made writable by the appropriate Team Providers. If any resource is not writable, the transaction rolls back.
A new Transaction::OPTION_VALIDATE_EDIT option allows clients to specify whether to perform validate-edit or not (by default, not). Additionally, instead of a boolean value, a custom implementation of a new ValidateEditSupport interface can be supplied to perform a validate-edit better suited to the client's needs. The default implementation simply checks with the editing domain that the resource is not read-only.
The org.eclipse.emf.workspace plug-in specializes the validate-edit support for its editing domains to use the Eclipse Workspace API for validate-edit. This provides a richer team-provider integration in IDE applications.
Because validate-edit is not enabled by default, clients that wish to use it must specify the OPTION_VALIDATE_EDIT on every command or operation execution. To simplify this, the TransactionalEditingDomain interface is extended to support default transaction options. Concrete editing domains may implement a new Adaptable interface to provide a DefaultOptions adapter that allows clients to set and query domain-wide default transaction options. The best opportunity for specifying default transaction options is in the factory implementation for the editing domain, so that they are in place before any client actually creates any transactions in that domain.