Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface) 
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]

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.

- it does the indirection (model.value(object, attrId))
- it is tuned for model access
- there are implementations for EMF, java beans, JDT etc

I am not saying the the openArchitectureWare metamodel is ideal,
but it is a very good starting point.

Look at Type (similar to EClass) and Feature (EStructuralFeature)
and Property (EAttribute and EReference).

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.

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);

This would then have the benefits of the IObservableModel and
openArchitectureWare metamodel with the power of EMF....


interface IObservableModel {
	// ask an object for what type it is
	EClassifier getClassifier(Object obj);
	EClass getClass(Object obj);
	EDataType getDataType(Object obj);
	
	// access of attributes
	Object value(Object obj,EStructuralFeature feature);
	Object value(Object obj,EStructuralFeature feature,boolean resolve);
	// setting attributes
	void set(Object obj, EStructuralFeature feature, Object value);
	void unset(Object obj, EStructuralFeature feature);
	boolean isSet(Object obj, EStructuralFeature feature);
	
	// 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);
	
	// methods to needed to create objects
	EClass getClassByName(String name);
	EDataType getDataTypeByName(String name);
	Object createInstance(EClassifier cl);
	
	Object callWithException(Object obj, EOperation operation, Object[] args) throws Exception;

	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);

	// 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). 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)....

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.....).

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...


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

Back to the top