Difference between revisions of "EMF/MQ, MT, and VF 1.2/New and Noteworthy"

Revision as of 13:15, 18 December 2007

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.

1.2 M4

The major new work in this milestone was the adoption of J2SE 5.0 language features (and API) in these components.

Query: J2SE 5.0 Adoption

The Query API exploits generic typing and other language features where appropriate. As an example, the extant condition classes for data types:

• BooleanCondition
• NumberCondition (which hitherto has been an abstract superclass for conditions specific to the various numeric types)
• StringCondition

are refactored as specializations of a new generic DataTypeCondition<T>. This new condition provides a convenient superclass for conditions on an EMF model's EDataTypes, particularly in conjunction with the new IDataTypeAdapter<T> interface for conversion of instance values to the required type. Extant adapter classes are refactored to implement this new interface.

Query: NumberCondition Enhancements

The NumberCondition<N> class is improved in two dimensions. First, it is no longer abstract, but generically implements all of the capabilities of its subclasses (such as NumberCondition::IntegerValue). Thus, these inner subclasses specific to each Java numeric primitive type are effectively obsoleted. One consequence of this improved NumberCondition is that it handles Java's arbitrary-precision BigInteger and BigDecimal types, which Ecore also supports as data types. In fact, any user-defined subclass of java.lang.Number that is comparable with itself is supported.

Also, support for relational operators and exclusive-bound range conditions is added, most conveniently using static factory methods:

• NumberCondition::between(N lowerBound, boolean lowerInclusive, N upperBound, boolean upperInclusive)
• NumberCondition::equals(N number)
• NumberCondition::greaterThan(N number)
• NumberCondition::greaterThanOrEquals(N number)
• etc.

Transaction: J2SE 5.0 Adoption

The Transaction API exploits generic typing and other language features where appropriate. For example:

• the result of the <T> T Adaptable::getAdapter(Class<? extends T>) method is now covariant with the adapterType parameter
• the RunnableWithResult<T> interface is parameterized by the result type
• a new <T> T TransactionUtil::runExclusive(TransactionalEditingDomain, RunnableWithResult<? extends T>) utility method returns the type of result declared by the runnable

Transaction: Transactional Editor Example

The org.eclipse.emf.workspace.examples.library.editor example plug-in demonstrating how to use the Transaction APIs to convert an EMF-generated editor to a transactional editor is updated to clarify the differences. In particular,

• the editor was synchronized with updates to the editor codegen templates of the last couple of EMF releases, to simplify comparison with the generated version
• methods that are hand-modified are marked as @generated NOT
• individual customizations of the generated code are indicated by //.CUSTOM: comments

Validation: J2SE 5.0 Adoption

The Validation framework exploits generic typing and other language features where appropriate. For example:

• the EvaluationMode<T> class is parameterized by the type of object that is validated in the indicated mode
• likewise, the IValidator<T> interface is parameterized by the type of object that it validates. The IBatchValidator validates EObjects and the ILiveValidator validates Notifications
• the <T,V extends IValidator<T>> V newValidator(EvaluationMode<T> mode) factory method's result is covariant with the evaluation mode parameter

Validation: Marker Severities

To simplify the handling of markers with different severities, new API is introduced in the MarkerUtil utility class that filters problems by severity before creating markers. See MarkerUtil::createMarkers(IStatus validationStatus, int severityMask) for details.

Other Bug Fixes

For details of other bugs fixed in this milestone, see the Query, Transaction, and Validation release notes.

1.2 M3

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.

Other Bug Fixes

For details of other bugs fixed in this milestone, see the Query, Transaction, and Validation release notes.