EMF/MQ, MT, and VF 1.1/New and Noteworthy
EMF Model Query, Model Transaction, and Validation Framework Release 1.1 New and Noteworthy Items.
For more details about the milestone-by-milestone development plan, see the 1.1 draft plan.
Back to Eclipse Modeling Framework.
- 1 1.1 M7
- 2 1.1 M6
- 3 1.1 M4
Improved Programmer's Guides
The major theme of this last milestone was improvement of the SDK documentation. To that end, the EMF Model Query, Model Transaction, and Validation Framework now have much expanded Programmer's Guides, discussing the major functional areas of each API, with UML class diagrams for easy reference and code snippets as concrete examples.
Note, also, that the EMF Workspace Integration documentation is now integrated into the EMF Model Transaction documentation, so that the help contents better reflects the component structure and keeps related API documentation togeter.
New Validation Constraint Provider Example
The org.eclipse.emf.validation.examples.ocl example plug-in now includes an example Constraint Provider implementation that loads OCL constraints, not from the plugin.xml file but from user-specified *.ocl documents.
A declaration of an instance of this example provider looks like:
where the referenced library.ocl file looks like:
Other Bug Fixes
Constraints run during validation can now be filtered using an IConstraintFilter. This filter accepts a constraint and a target EObject and returns a boolean value indicating whether the target should be validated against the constraint. This allows clients to run a subset of constraints during validation. The constraint filter can be set using new methods added to IValidator.html. If multiple constraint filters are added to a validator, they are combined using AND logic.
Clients can now listen to changes made to ConstraintRegistry, including the following events:
- Constraint enablement
- Constraint disablement
- Constraint registration
- Constraint deregistration
- Category addition
- Category removal
Clients listen to constraint changes by implementing the IConstraintListener interface and registering themselves through new methods added to ConstraintRegistry.
Extensible Constraints Preference Page
Factored out the controls on the constraints preference page into a block which is now accessible through public API. This provides the ability to create a custom constraints preference page. Clients add the block using ConstraintsSelectionBlock and can customize the constraints shown in the block using an IConstraintFilter.
Custom Validation Event Types
Custom event types can now be contributed to EMF validation through the eventTypes extension point. Previously, when live validation validated notifications, the event type of the notification was compared against a list of predefined types in EMFEventTypes. If the event type was not in EMFEventTypes, the notification is not validated. Live validation will now accept notifications with event types that were contributed through the eventTypes extension point.
Clients can optionally contribute an INotificationGenerator which takes existing notifications and generates additional notifications with custom event types. Live validation uses all contributed notification generators to generate its list of notifications to validate.
Notification Filtering in Live Validation
The notifications accepted during live validation can now be filtered using a notification filter. This notification filter can be set using new methods added to ILiveValidator. If no notification filter is set on the live validator, the existing notification filtering behaviour is used (EObject must be attached to a resource).
Multiple Results from one Validation Constraint
A single constraint can now report multiple results, for different but related problems in one or more model elements. New utilities on the ConstraintStatus class make it easy to create multiple results and combine them into a single multi-status (which also is an IConstraintStatus.
Removing Resources from Transactional Editing Domains
Resources and model elements can now be safely removed from the grip of a transactional editing domain. New utilities on the TransactionUtil class allow a resource or object that has already been detached from the editing domain's resource set to be released from the "transaction protocol." This is particularly useful when the resource/object in question is to be moved into another resource set context, which may or may not be controlled by a transactional editing domain.