Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 339705

Summary:	Support adaptation of selection to EObject
Product:	[Modeling] TMF	Reporter:	Ed Willink <ed>
Component:	Xtext Backlog	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	NEW ---	QA Contact:
Severity:	enhancement
Priority:	P5	CC:	jan
Version:	2.0.0
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Ed Willink

2011-03-11 10:20:35 EST

The OCL Console is an example of an extended modeling application that exploits the current selection, by discovering that it is an EObject or is adaptable to an EObject. This for instance allows the Sample Ecore Editor to be a selection source.

The Xtext Outline nodes support adaptation but only to an EClass. This can be worked around by an Xtext aware selection listener by finding the URI. It would be helpful if the Xtext Outline directly supported return of the underlying EObject.

The Xtext Editor text selections do not support adaptation at all, and it is fairly hard to workaround this outside the editor. It would again be helpful if the Xtext Text selection responded to getAdapter(EObject.class) to return the semantic object.

Comment 1 Jan Koehnlein

2011-03-14 04:17:03 EDT

To be honest, the lack of such an API is on purpose.

In Xtext, EObjects come and go as the parser replaces subtrees of the model rather than reconcile on changes in the editor. The reparse even runs in a worker thread (not the UI thread) as it is toggled by the reconciler. This is why we introduced the document.readOnly() and document.modify() APIs: Within an IUnitOfWork, you have a lock on the model to assure you no-one else is making changes concurrently.

Passing EObjects or even the EMF Resource holding the semantic model around can therefore not only lead to inconsistencies and references to stale model elements but also to serious memory leaks. The first thing an UI action usually does is to store the selection in a local field. As models are trees and we don't break containment references by default for performance reasons, the garbage collector will not prune stale model trees.

Recent newsgroup posts show that many of our users are not aware of these concurrency issues. That's why I consider adding API that facilitates direct EObject access dangerous. We should rather adapt to the EObject's URI and write actions that read/write the model element in an IUnitOfWork.

So the most likely thing we implement is some abstract action classes adapting to URI and encapsulating the resolution of the element and the run method within the same IUnitOfWork. OTOH, the fragment URI does not carry type information, so IEObjectDescription would be a better choice. You see, things are becoming more and more complex and possible solutions might vary a lot with regard to the usecase.

Comment 2 Ed Willink

2011-03-14 04:31:39 EDT

I think getAdapter(IEObjectDescription.class) probably works for me.