Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' workbench UI

Hi,


Note that I am -not- saying that this would be the final API but I think it should be treated as 'close'.
Ed, I'm one of those pseudo-purists...for the clients we want to con into using this I'm highly in favor of providing the absolutely simplest API that can provide the necessary capabilities (regardless of the implementation). Rather than exposing EObject directly how about a method that returns the ModelElement's underlying 'implementation' object (something like "Object accessImplementation()", sort of like C's 'escape to assembler'..;-) ? This would keep the API implementation neutral while still allowing those 'in the know' to do their tricks (note that this would also apply to my current IMemento ScopedPreferenceStore and IConfiguration element wrappers).

I’d, be in favor for that approach as well. I’d really like to see EMF in place there. However I also see this is a kind of “implementation detail”. One should be able to access the underlying EObject but not necessarily forced to deal with it.


BTW, if we decide that we need concrete API for the particular 'classes' of element we have (like "Stack" and "MenuItem") that provide accessor methods I'd recommend that these be -generated- from the model.
I'm also a 'don't write boilerplate' zealot and this is a classic case.

+1. I’d volunteer  to help there.

Kevin, I think we'll be in a better position to judge once we get this. We're walking a line between size/complexity and capability; the current implementation is small, simple and sufficient unto the day...today. However I don't think we want to be in a position where we have to devote effort into extending it. Having EMF backing the API means that all those 'enhancement' requests we get for the model just turn into exposing more of EMF's underlying capabilities. As long as it's not too costly and we can adequately hide its implementation details from our clients I think it's a win.

Once you have the model in place, I’d be willing to have a look at the Scripting you’ve done for e4. This should then be quite easy with existing modeling tools. Using EMF’s notify-API the “Workbench” (meaning the interested parties there) can listen to the changes on a model element.

Cheers,
Bernd


Back to the top