Hi, Team,
So, this now provides the usual EMF integrations for the façade API. Note that there are still limitations as compared to, for example, the UML metamodel, including:
- all features of the façade metaclasses are derived, being computed on demand from the underlying UML model; the façade objects are wrappers for the UML
- as such, there is no support for serialization (persistence) of façade instances. They are persisted as a UML model only
- however, many of these derived features in the façade do notify, which makes them suitable for triggering updates in the UI and such, but not for undo/redo, because all edits are actually performed on the UML model anyways and the façade is not maintained in any resource (and so not in the resource set and the editing domain that controls it). The features that support notification are the ones that seem most like the “structural” properties that one would edit and present in the UI. See the wiki for a complete list
- direct creation of the façade objects via the static generated EFactory is not supported. In fact, I now have experimental support for caching of façade instances by soft reference, to let the garbage collector purge them under memory pressure. This is not enabled by default, but the JUnit launch configurations and all of my own run-time workbench launch configurations enable it for testing until I see how it shakes out in practice
Once again, there is a lot of code here to review. I encourage feed-back. For now, I shall continue with state machine inheritance, adding the state machine concepts to this façade to support the inheritance work in the Model Explorer, the Properties View, and the diagram. On the branch, of course.
