| Re: [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface) |
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