[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface)
|
Ed
Comments below.
Merks wrote:
> Typical examples for the need of read-only metamodels
> - database persistence
> - data-binding
I'm not so sure abut these two. You want might want to store into the
data base, or update the data based on changes in the GUI
I am talking about the metamodel not the model. The model changes
and needs information but the metamodel is (for the consumer)
static. Hmm, well in the case of a database query, the result
of the query comes back with some meta information about the
date. In this case the metamodel is not read-only. But for
making POJOs persistable, you need a metamodel to "reason"
about the model.
> Ok, here's an example where you need a modifiable metamodel:
Probably in every case you've used the word meta model, you really just
mean model. Most often meta models are quite rigid and not likely to
change so much. It's often hard to change a meta model once instances
exists.
OOPS you are right!
M3 - meta-meta-model
M2 - meta-model - ecore
M1 - model - the ecore instance (the definition of MyClass)
M0 - instance - instances of the model stored as xmi
I have been thinking about code generation, where I generate
code from M0 models -- this shifts the stack one up....
This terminology is confusing at times -- depending at what
you look at...
> ad-hoc data-structures like IMemento. But with something like
> my MagicInterfaces or generated code, the user is not exposed
> too the fact that the metamodel is modifiable.
>
> I think in the realm of UI there is a lot you can do if you have
> a strong metamodel. The EMF tools show quite nicely what you can do
> with a good metamodel.
>
> But unfortunately, EMF is viral like GPL. If you want to use it you
> have to make your objects EObject. The oaw metamodel is similar
> to ecore but it is not viral (because you can use it for non
> openArchitectureWare and non EMF objects).
True enough. Though if you want your model to produce notifications,
model (M1) or instance (M0) create notifications?
which is a key thing for most of the things we've been talking about,
the notification generating code itself is viral in nature. Only
Aspects provide a kind of non-viral approach, but even then, it's
because the virus is hidden...
True, but there are different types of notifications:
- java PropertyChangeSupport (with no good solution for
changes in collections)
- databinding change support
- emf notifications
- ...
> For example, you have to write your own helper to interpret CQL
> statements that are associated with volatile attributes (at least
> that is what I remember you told me at eclipsecon). But like
> in openArchitectureWare it should be possible to allow extensions
> to weave in additional attributes. Code that might get generated
> but is not available in dynamic models. Like the OAW team, and
> many others, I have created my own engine to deal with dynamically
> calculated attributes. I wish there was a general mechanism...
This is precisely how simple things become complex over time. Java
provides maps for such things...
... and that's why I'd like to see some unification and support
in the platform....
>
> ... in my annotation driven UI the EMF implementation of default values
> annoyed me, because unsetting a value does not get back the default
> value (or something strange like this).
Yes, it does. :-P If eIsSet is false, it should return the default
value, and calling eUnset should cause eIsSet to return false.
Yeah you are right - I think I did not realize at that time that
providing a default is not enough -- the feature also has to be
unsettable...
Michael
