| Re: [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface) |
Michael,
Comments below. I look forward to the e4 summit! I see you'll be attending, so that will be cool.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 05/02/2008 12:51:29 AM:
> OOPS: I hit Send instead of Save (I wanted to review the mail
> tomorrow before I send it)... So here's the quick review without
> sleep... [Minimal changes only some typos fixed]
Don't you hate it when that happens!
>
> Boris and Ed,
>
> have you looked at the openArchitectureWare MetaModel [1][2]? It is similar
> to IObservableModel [3] but it seems to be more complete. It is
> missing notifications though.
I think the intent is a quite a different though...
>
> - it does the indirection (model.value(object, attrId))
> - it is tuned for model access
> - there are implementations for EMF, java beans, JDT etc
I'm not sure of the specifics, but I expect the need for it is much like in JET where you want to write templates that traverse a data string in a uniform way. I.e., it's effectively a requirement to write scripts against arbitrary data structures all of which you want to view as being typed objects with properties...
>
> I am not saying the the openArchitectureWare metamodel is ideal,
> but it is a very good starting point.
It's certainly a close analog...
>
> Look at Type (similar to EClass) and Feature (EStructuralFeature)
> and Property (EAttribute and EReference).
Most of their stuff is in modeling CVS somewhere...
>
> This meta model interface has been tuned to be used with different
> implementations. EMF is just one implementation. In that sense it
> is a higher level abstraction.
No, I wouldn't describe it as that. It's very much is a facade that is not so much designed to hide anything but rather to mirror EMF closely and even to provide the same kinds of facilities as EMF, but to do so for beans and other structures as well.
>
> BUT I think it should also be possible to start with the EMF metamodel.
> Maybe it can be used to represent the type system and there is a
> facade (or whatever) that allows indirect access:
>
> EClass cl=facade.getClass(object);
> EStructuralFeature f= cl.getEStructuralFeature(attrId);
> facade.value(object,f);
Yes, I could imagine such a thing too.
>
> This would then have the benefits of the IObservableModel and
> openArchitectureWare metamodel with the power of EMF....
Again, I think the intent is a little different and I'm not sure those differences unimportant.
>
>
> interface IObservableModel {
> // ask an object for what type it is
> EClassifier getClassifier(Object obj);
> EClass getClass(Object obj);
> EDataType getDataType(Object obj);
Note that in general, given a Java object, there isn't necessarily only one EDataType to represent that type of object.
>
> // access of attributes
> Object value(Object obj,EStructuralFeature feature);
> Object value(Object obj,EStructuralFeature feature,boolean resolve);
Boris will likely say, what the heck does resolve mean. :-P Obviously I do know what you mean.
> // setting attributes
> void set(Object obj, EStructuralFeature feature, Object value);
> void unset(Object obj, EStructuralFeature feature);
This is where I think one of the big differences lie. When seen as a way of inducing/deducing a view from an underlying model, many if not all of the properties are likely to be derived and hence not editable. Imagine the label of the tree node for a person being the first name and the last name without there being a full name feature in the model... In that sense, the "model" of the view, is very different from the underlying data model itself. Things like fonts and colors typically have no meaning in a data model.
> boolean isSet(Object obj, EStructuralFeature feature);
If data binding an things like the properties view considered this aspect a little better, stuff like the restore button in the properties view could be disabled when the feature is already in the unset/default state...
>
> // some convenience methods using strings instead of features
> Object value(Object obj, String feature);
> void set(Object obj, String feature,Object value);
> void unset(Object obj, String feature);
> boolean isSet(Object obj, String feature);
Yes, looking up the feature by name. I can also imagine useful coercions being involved, must like the SDOUtil help methods that would let you set an integer property from a string value...
>
> // methods to needed to create objects
> EClass getClassByName(String name);
Often many different models will use the same name...
> EDataType getDataTypeByName(String name);
> Object createInstance(EClassifier cl);
Typically data type values are not created in this way. For example, you couldn't just create java.lang.String this way since you can't change it once it exists.
>
> Object callWithException(Object obj, EOperation operation,
> Object[] args) throws Exception;
Ooo. Like the eInvoke I've always wanted but have never had time to support. It would be so cool if models could describe behavior in any extensible scripting language...
>
> Object call(Object obj, EOperation operation, Object[] args);
>
> // borrowed from IObservableModel
> /** Returns the length of the given array */
> int length(Object array);
>
> /** Returns the element at the given index of
> the given array */
> Object element(Object array, int index);
I never did quite understand these... Multi-vaued features in EMF are lists and can be manipulated directly. Of course that doesn't fit well with this design where observable model controls all data access.
>
> // TODO some way to manipulate arrays/lists and maps
>
> /** Adds a listener */
> void addModelChangeListener(IModelChangeListener listener);
>
> /** Removes a listener */
> void removeModelChangeListener(IModelChangeListener listener);
> }
>
> Essentially, this class should cover the self manipulation methods
> of EObject (including EList and EMap).
You'd have to add effectively the full set of methods you can use with lists, like add, remove, contains...
> But it would allow to have
> models that do not have a IsA relationship to EObject. As Ed points
> out all the time: we will end up with a metamodel like ecore anyway.
> So, why not starting with ecore as metamodel (instead of Attr)....
Hehehehe. I don't see what Boris is proposing as a general purpose meta model for general purpose data models though... It's easy to see it that way though...
>
> Obviously, modifications of the ecore (meta)model cannot supported for
> all underlying type systems. I'd like to have a clear separation
> between accessing a metamodel (a kind of read-only access) and
> metamodel manipulation (read-write access). But maybe that's my
> personal opinion (I also hate that there are no interfaces for
> read-only collections, and that java supports them by decorating
> them and then throwing runtime exceptions.....).
Architecture always seems to be a comprimise... Imagine the impact on the class hiearchies to have such a split...
>
> In a world like this it also makes no sense that the ecore classes
> (EModelElement, EClass, EFeature etc) extend EObject.... If you
> want to introspect EClass you'd use IObservableModel...
An Ecore model is just a model as well as being the meta model for other models. so a world where it's not sensible is an odd world for me.
>
>
> Michael
>
> [1] http://oaw-forum.itemis.de/pub/api/4.
> 2dev/org/openarchitectureware/type/package-summary.html
> [2] http://architecturware.cvs.sourceforge.
> net/architecturware/oaw_v4/core/core.
> expressions/main/src/org/openarchitectureware/type/
> [3] http://dev.eclipse.org/viewcvs/index.cgi/e4-incubator/ui/org.
> eclipse.e4.
> contentmodel/src/org/eclipse/core/databinding/observable/model/IObservableModel.
> java?revision=MAIN&view=markup
>
>
> > Eric Moffatt wrote:
> > > What I'm hoping to be able to
> > > do is to at least allow our users to have a 'common' api through which
> > > they can access the underlying information in a consistent manner; we
> > > make one more API but they see at least 3 -less-.
> >
> > This sounds interesting and is worth exploring.
> >
> > I would like to discuss if the "one more API" could be something that
> > does not require wrappering of all the underlying objects from models we
> > already have. One example of this can be found in the
> > "org.eclipse.e4.contentmodel" project in the e4 incubator component - it
> > was modeled after JSON and looks similar to this:
> >
> > interface IObservableModel {
> > /** Returns the opaque root object */
> > Object root();
> >
> > /** Returns the attributes supported by the
> > given opaque object */
> > Attr[] attributes(Object opaque);
> >
> > /** Returns the attribute value for the given
> > opaque object and attribute id */
> > Object value(Object opaque, String attributeId);
> >
> > /** Returns the length of the given array */
> > int length(Object array);
> >
> > /** Returns the element at the given index of
> > the given array */
> > Object element(Object array, int index);
> >
> > /** Adds a listener */
> > void addModelChangeListener(IModelChangeListener listener);
> >
> > /** Removes a listener */
> > void removeModelChangeListener(IModelChangeListener listener);
> > }
> >
> > class Attr {
> > String id;
> > /** The type of the attribute value, one of
> > Object/Array/String/Number... */
> > Type type;
> > }
> >
> > Think of it as a "tree content with attributes provider" that is similar
> > to a tree content / label provider pair but more general in that it is
> > not restricted to the attributes "label" and "image".
> >
> > The additional indirection ("model.value(object, attrId)" instead of
> > "object.getValue(attrId)"), similar to the indirection in the JFace
> > providers, allows you to get away without wrappers around all the "real"
> > objects. Instead, you hand out the real objects, but clients have to
> > treat them as opaque object references that can only be accessed through
> > the provider.
> >
> > Unfortunately, if used directly from Java code, an API like this does
> > not lead to very readable code. The only defense I have against this is
> > that I don't think you would want to program against this API directly.
> > It would make a nice basis for data binding though - who says you have
> > to program the API directly?
> >
> > Boris
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev