> > 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?
That was my interpretation as well. Its a shallow but consistent model for
the UI viewer, just as content providers are, but at a higher level. I
found it handy for building the web demo we showed at the BOF. It does
however lead to ambiguities around level of modelling (do I model the
entire perspective, or just the trees/lists? what about the connections
between them?) and around reuse (if I have two navigators that are very
similar how do I reuse the observable or are they simple enough to write
that writing two isn't a big deal?). In the latter case they are trivial
to write except of course the delta processing is hard work and that part
you would like to reuse.
Kevin
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
