| Re: [eclipse-incubator-e4-dev] YAMI (Yet Another Model Interface) |
Boris,
Comment below.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 313)
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/29/2008 12:08:14 AM:
> 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.
Exploration is always cool...
>
> 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.
It seems to me that most of the APIs have hidden implementation classes so ensuring that these implementation classes have a common underlying API would be sufficient as well...
> 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();
I was assuming this pattern would be like stateless adapters, but given that this method isn't passed the object, doesn't this imply IObservableModel must be stateful?
>
> /** 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);
The lack of a set implies that this is a read only API, which is cool for viewing, but something line IMemento supports update as well. Would it make sense to support an Attr-based one to avoid the cost of attributeId -> Attr mapping for each access?
>
> /** Returns the length of the given array */
> int length(Object array);
Are these arrays returned by value? Does this return -1 if the object isn't an array? Would this allow us to support Collections in general?
>
> /** Returns the element at the given index of
> the given array */
> Object element(Object array, int index);
I guess this throws runtime exceptions in some cases.
>
> /** 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;
Would just using java.lang.Class be sufficient?
> }
I guess that answers my question about no lists. Limiting the types is certainly nice when you want to process instances via this API, but isn't so nice when you're a modeler. But then the idea here isn't focused on supporting a generall data model but rather a mechanism for "viewing" a data modeling.
>
> 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".
I see. That makes good sense. So even things like parent and child are handled uniformly...
>
> 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.
I guess in some cases an IObservableModel might consider objects to be outside of its domain?
>
> 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?
I think this is a very cool idea. I could see how this could be applied very nicely against an underlying EMF model to induce a virtual structure for the purposes of viewing in a way that's much more flexible than the more rigid content providers. It could be used to view IConfigurationElement and IMemento instances as well. I don't think it's intended as a way to unify general purpose data manipulation for these two things. In that way, I don't consider it a YAMI. :-P Rather it seems to be a way to unify all the JFace content providers as well as avoiding a proliferation of additional ones in the future. Am I interpretting this correctly?
>
> Boris_______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev