This example describes the usage of model management framework within the SDK. -It demonstrates some of the model management capabilities (editing domain, validation -batch notification, semantic procedures etc.) applied to library models. +It demonstrates some of the model management capabilities (editing domain, validation, +batched notification, semantic procedures etc.) applied to library models.
MUndoInterval)| Version: 0.1 | -Date: June 08, 2005 | +Version: 0.2 | +Date: Dec. 28, 2005 | +
-The Model Service Layer(MSL) provides a number of facilities to ease model management: +The Model Service Layer (MSL) provides a number of facilities to ease model management: model modification semantics, uniform resource creation and loading, uniform listener registration, batching of notifications, live validation with automatic modification abandonment, copy/paste support, automated pathmap support and additional metamodel support. @@ -203,190 +203,6 @@ editingDomain.saveResource(r1); -
-The MSL's default resource implementation conforms to the
-ILogicalResource
-interface. This resource creates an in-memory logical view of an EMF tree
-(or forest) structure that is persisted in multiple physical resources, all of
-which are XMI-compliant. The central concept in the logical-to-physical mapping
-of an MSL resource is the "separate" element. A separate elements is persisted
-in a different, or separate, physical resource than its container.
-
-To obtain a logical resource, use the editing domain to create a resource as
-described above and then get a view of it as
-an ILogicalResource.
-To store a model element in its own physical resource, just ask the logical
-resource to separate it into a new resource on a URI of your choosing. Don't
-forget to ask first whether it can be separated (the metamodel may
-implement rules restricting what can be separated; see below):
-
-Resource r1 =
- editingDomain.createResource("file://c:/eclipse/workspace/aProject/test.rmplibrary",
- RMPLibraryPackage.eINSTANCE.getLibrary());
-ILogicalResource logical = editingDomain.asLogicalResource(r1);
-
-// ... fill the resource with contents
-
-EObject element = // ... find an element to be separated
-
-if (logical.canSeparate(element)) {
- try {
- logical.separate(
- element,
- URI.createURI("file://c:/eclipse/workspace/aProject/test.sub1.rmplibrary"));
- } catch (CannotSeparateException e) {
- System.out.println("Could not separate the element: " + element);
- e.printStackTrace();
- }
-}
-
-editingDomain.saveResource(logical); // or logical.save(Collections.EMPTY_MAP);
-
--We now have one logical resource stored in two files. -
-Note the use of the ILogicalResource MEditingDomain.asLogicalResource(Resource)
-method to obtain a view of an arbitrary resource as a logical resource. This is
-necessary because the editing domain might actually instantiate any resource
-implementation, not necessarily a logical resource, depending on the registered
-resource factories. If the resource is not actually a logical resource, then
-this method creates a wrapper that provides compatibility with the logical
-resource API.
-
-In the snippet above, we catch CannotSeparateException despite
-being informed that the separation would be permitted because there may be
-unexpected conditions that prevent the separation from succeeding (such as
-incorrect file permissions). No attempt is made to actually persist the new
-physical resource until the logical resource is saved, but a metamodel extension
-might be proactive in checking even at this point whether certain I/O limitations
-would be exceeded.
-
-To do the inverse of a separation operation, we can absorb an element -from a separate resource into the same resource as its container: -
- -
-if (logical.isSeparate(element)) {
- try {
- logical.absorb(element);
- } catch (CannotAbsorbException e) {
- System.out.println("Could not absorb the element: " + element);
- e.printStackTrace();
- }
-}
-
-editingDomain.saveResource(logical);
-
--Now, our logical resource is again stored in a single file. Note that the -test.sub1.rmplibrary file is not deleted, though it will be empty. -This simplifies comparing and merging changes with a source control repository. -Note also that, like separation, absorption can fail unexpectedly. -
-How does the MSL framework determine whether an element can be separated? By
-default, any element of any EMF metamodel can be separated, unless it is a
-root of the logical resource or has already been separated. However, a metamodel
-provider or an application may for some reason want to restrict the elements
-that may be separated. This is accomplished by registering a policy on the
-org.eclipse.gmf.runtime.emf.core.resourcePolicies
-extension point:
-
-<extension - point="org.eclipse.gmf.runtime.emf.core.resourcePolicies"> - <policy - class="org.eclipse.gmf.examples.runtime.emf.resources.LibraryResourcePolicy" - nsURI="http:///com/ibm/xtools/emf/metamodel/example/pde/rmplibrary.ecore/1.0.0"/> -</extension> --
-The policy implements the
-ILogicalResourcePolicy
-interface, usually by extending the AbstractLogicalResourcePolicy
-class. Our example allows only libraries to be separated:
-
-public class LibraryResourcePolicy
- extends AbstractLogicalResourcePolicy {
-
- public boolean canSeparate(ILogicalResource resource, EObject eObject) {
- return eObject instanceof Library;
- }
-}
-
--Policies can also suggest default URIs for new physical resources according to -some application-specific naming system, implement extra checks when clients -perform separations or absorptions, etc. -
-By default, logical resources initially load only the root resource (corresponding
-to the logical URI) and automatically load other resources as they are needed
-by access of containment references or proxy resolution. The ILogicalResource
-interface defines load options to disable incremental loading or to initially
-load the entire logical resource contents. Automatic incremental loading of
-separate objects from containment references requires a custom EList
-that loads the necessary resources on demand. Two convenient implementations
-are provided by the MSL for metamodels to use in place of the
-EObjectContainmentEList and EObjectContainmentWithInverseEList
-classes. However, it may be necessary for a metamodel to be deployable without
-the MSL, in a "pure EMF" configuration. To address this need, the
-resourcePolicies extension point allows the registration of
-an EFactory that creates alternative *Impl classes
-that use these special lists, to be deployed only in MSL configurations:
-
-<extension - point="org.eclipse.gmf.runtime.emf.core.resourcePolicies"> - <efactory - class="org.eclipse.gmf.examples.runtime.emf.resources.LoadingRMPLibraryFactoryImpl" - nsURI="http:///com/ibm/xtools/emf/metamodel/example/pde/rmplibrary.ecore/1.0.0"/> -</extension> --
-The MSL framework will use this factory instead of the default when loading
-a logical resource; it does not need to be used by clients to create new objects.
-In our example, only libraries can be separated and only libraries can contain
-other libraries, so our factory simply creates a specialization of the default
-LibraryImpl class:
-
-public class LoadingRMPLibraryFactoryImpl
- extends RMPLibraryFactoryImpl {
-
- public Library createLibrary() {
- return new LoadingLibraryImpl();
- }
-
- public EPackage getEPackage() {
- return RMPLibraryPackage.eINSTANCE;
- }
-}
-
-class LoadingLibraryImpl
- extends LibraryImpl {
-
- public LoadingLibraryImpl() {
- super();
-
- // use the custom containment-with-inverse list to perform automatic
- // loading of contained elements in this feature. This pre-empts
- // the superclass's lazy initialization of this list
- branches = new EObjectContainmentWithInverseLoadingEList(
- Library.class, this, RMPLibraryPackage.LIBRARY__BRANCHES,
- RMPLibraryPackage.LIBRARY__PARENT_BRANCH);
- }
-}
-
--Note how we only concern ourselves here with overriding the implementation of -those features that will be able to contain separate elements. -
-doExecute()
method to perform some operation. All model commands have an associated undo interval, through which they can be undone
or redone.
-ILogicalResource
-interface provides a logical view in memory of a tree structure that is persisted in multiple physical resources.
-Metamodel-specific customizations are provided as ILogicalResourcePolicy implementations that define
-the locations in a logical structure where boundaries in the physical structure are permitted and provide automatic
-naming of physical resources. EFactory implementations registered on this extension point provide support
-for incremental loading of logical resources.EventTypes.CREATE, EventTypes.DESTROYEventTypes.IMPORT, EventTypes.EXPORTEventTypes.UNRESOLVEEventTypes.SEPARATE, EventTypes.ABSORB, EventTypes.LOADEventTypes.UNRESOLVEIMetamodelSupportProvider.
The implementation of the interface method getMetamodelSupport returns the IMetamodelSupport object.