Re: [eclipse-incubator-e4-dev] Initial discussion onthe'modelled'workben

["Eric Moffatt" <emoffatt@xxxxxxxxx>]

Ed, it's not just beans etc, the current demo shows up to 'map' the current IConfigurationElement ScopedPreferenceStore and IMememto 'models' and expose them as 'ModelElements' (although it'll likely take a few more rounds to figure out what the API for these is...;-). Whatever the API, this consolidation is I believe essential to the strategic goal of simplifying the Workbench.

BTW, I get it...;-) Your comments abut undo/redo, save/restore and meta-data are precisely the capabilities that will be needed at some point and that EMF already has a robust implementation of.

So, if EMF doesn't show up in the model's API, what does it look like? I think that there is a difference between the 'core' model API (the eventual Model Element/Domain) and additional API that expose domain specific 'types' through classes/methods/meta-models/utilities (i.e. "Stack.addView(id)...", can we agree to treat them separately?

Note that we're already committed having all the existing API work, I just need a model to make it work against..;-).

My comments about enforcing a widget life-cycle protocol are pure rendering code (just good SWT/JFace practice), not specific to the model itself (probably why you found it uninteresting..;-), any number of different rendering engines may be capable of displaying a particular model fragment.

'til tomorrow,
Eric