Eric, I can see appeal of hiding behind a new API. It creates a sense of purity and isolation that seems like goodness on the surface. But of course hiding behind a new API requires thought about exactly what's in that API. I.e., what methods are all available on Type and Property? How is a notification represented to ensure that the information it provides is 100% complete? Naturally one could look to all the EMF APIs (or perhaps the SDO ones) for that information and duplicate it, while presumably simplifying it, to produce another EMF-like API. This would of course result in yet one more new API (a metamodel), in addition to the new UI model's API itself, and unfortunately that seems highly unlikely to produce a result that's in actual fact simpler or smaller since those traits generally come from reuse of common designs and existing byte code. With regard to IMemento, EMF already fully supports XML persistence of instances, so I'm not sure there's much need to implement that in yet another way as well. Also, Marcelo has prototyped a JSON serialization for EMF instances, in case that's a valuable thing...
Keep in mind that there is a very large modeling community exploiting EMF
models as well as providing services around them, so in terms of growing a
large e4 community, leveraging existing ones seems like a good approach, at
least on the surface. For example, I could imagine designing a general
purpose event model, analogous to the current change model, for recording
model change events in order to support playback and reverse. Such a thing
would have broad applicability across the model space, which is of course
one of the advantages of having one common metamodel to bind all the other
models...
Ed Merks/Toronto/[EMAIL PROTECTED]
mailto: [EMAIL PROTECTED]
905-413-3265 (t/l 313)
"Eric Moffatt"
<[EMAIL PROTECTED]
om> To
Sent by: "E4 developer list"
eclipse-incubator <[EMAIL PROTECTED]
[EMAIL PROTECTED] rg>
clipse.org cc
Subject
04/23/2008 03:03 Re: [eclipse-incubator-e4-dev] What
PM I dislike about using EMF for
e4...
Please respond to
E4 developer list
<eclipse-incubato
[EMAIL PROTECTED]
org>
On Thu, Apr 17, 2008 at 11:15 AM, Michael Scharf <
[EMAIL PROTECTED]> wrote:
[snip!]
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.
Michael, I really like the idea of using an Adapter pattern to gain access
to any underlying implementation details. I also think that there should be
-no- EMF classes/ifaces in the modeling API (including the event
notification). Using an adapter (rather than the more specific
'getImplementation' method) opens the door for some very interesting
cross-model capabilities. For example model implementors (i.e. EMF) could
not only support 'adapting' a ModelElement to EObject but could also
support 'adapting' to a databinding 'Observable' (or JSON...).
Another example (that I might use) is to adapt a particular Model to
'IMemento' so that I can integrate it with the existing API structure (all
of our save/restore code uses IMemento as the persistence API).
Eric
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
<<inline: graycol.gif>>
<<inline: pic11273.gif>>
<<inline: ecblank.gif>>
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
