Michael Scharf schrieb:
I think using a formal model is a great idea. It allows to reason about the model and you can use all the modeling tools for the model. However I dislike the fact that the generated EMF code makes all objects extend EObject. EObject adds a set of (reflection) methods that are not relevant for the domain (of e4 presentation). I think the better approach would be to use something like IAdptable to adapt a presentation object to EObject (or to something that allows reflection).
We already talked about this. EMF allows you to generate the interfaces without any Ecore specific things.
**Break the Is-A relation and make it a Has-A realtion** I really like here the approach that openArchitectureWare has taken. In order to access the model via reflection, they have a MetaModel that allows reflective access to the model: http://tinyurl.com/3ummkv (javadoc) http://tinyurl.com/4rher7 (cvs) The basic idea is that your model has no (public) is-a relationship to a meta-model implementation, but there is a kind of adapter that gives you access to the meta-model. If we don't like to have the adapter, then a getMetaModel() or getType() method on the model would turn the is-a into a has-a relationship. The big advantage is that there is no is-a relationship of the model objects (interfaces) to the underlying implementation. So, you can change the meta-model implementation without breaking clients. With the meta-model as public part of the model you create tight coupling that makes me feel uncomfortable. Another advantage of a pluggable meta-model adapter is that we could provide a rich reflective access to objects that are not EMF objects. In addition it would allow us to have a uniform and rich meta-model that can be used for scripting. If objects created by scripting engines would provide an adapter to such a meta-model, then you can use the same meta-model interfaces as for the EMF objects. Similar to the plain meta-model access, there should be another abstraction for managing event listeners (the EMF Notifier mechanism). This would allow to implement Eric Moffatts idea of having one central "event funnel"...
I'm not sure. Do you suggest that we translate EMF-Notifications into another Event-System. I'd like to stay with EMF-Notifications but let the clients register themselves not directly on the model but on point which dispatches events coming from the model to the clients registered.
Tom -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl leiter softwareentwicklung/CSO ------------------------------------------------------------------------ eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834 _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
